Engineering · Automotive Cybersecurity · Germany and Europe
Automotive Penetration Testing in Germany and Europe
ECU and vehicle penetration testing for OEMs and Tier-1 suppliers in Germany and across Europe: ECUs, software-defined vehicle stacks, telematics, charging and backends attacked on the bench by engineers who build the same stacks — then written up as the verification evidence UNECE R155 Annex 5 and ISO/SAE 21434 assessments expect.
Reviewed by Shreyansh, Founder & CTO, Agnile Technologies •
What is automotive penetration testing in Europe?
Automotive penetration testing in Europe is the testing UNECE R155 paragraph 7.3.6 requires — “appropriate and sufficient testing to verify the effectiveness of the security measures implemented” — demonstrated at type approval. Agnile Technologies tests ECUs, software-defined vehicle stacks, telematics, charging and backends for OEMs and Tier-1s in Germany and across Europe, remotely from Bengaluru and on-site, with findings written to ISO/SAE 21434 for the technical services that report to KBA, RDW and other approval authorities.
Context
What European Type Approval Expects From Testing
UNECE R155 has applied to every new car, van, truck and bus registered in the EU since 7 July 2024. It is outcome-oriented: it does not name a test method, but it leaves no room to skip one.
Testing is a stated obligation
Paragraph 7.3.6 requires the manufacturer to perform appropriate and sufficient testing to verify the effectiveness of the security measures implemented. Annex 5 lists 69 threat and vulnerability examples the manufacturer’s risk assessment must consider, with mitigations in Parts B and C; testing is how you demonstrate the chosen mitigations work rather than assert it. Our UNECE R155 compliance page covers the CSMS and vehicle-type sides in detail.
ISO/SAE 21434 is the method assessors read against
Technical services expect the engineering behind the regulation to follow ISO/SAE 21434: verification in Clause 10, validation in Clause 11, attack feasibility in Clause 15, and a Cybersecurity Case that ties them together. A pentest delivered as a generic vulnerability list has to be translated by your team before an assessor can use it. Ours is written in that structure from the first finding.
The obligation cascades to Tier-1s
R155 regulates the OEM, but no OEM passes an assessment without supplier-side evidence. Cybersecurity Interface Agreements under ISO/SAE 21434 Clause 7 push verification obligations to the component supplier — which is why Tier-1 product-security teams are a common buyer of a component-level pentest in Germany, Austria, France and the Nordics.
Germany
Automotive Penetration Testing in Germany: KBA, Technical Services, TISAX and Authorisation
German OEMs and Tier-1s sit inside the densest regulatory and contractual stack in the industry. A test for a German programme has to satisfy all of it at once.
- KBA and its designated technical services. The Kraftfahrt-Bundesamt grants R155 and R156 approvals on the basis of assessments performed by technical services it has designated for cybersecurity — TÜV SÜD (designated June 2021), TÜV Rheinland and GTÜ's Ateel among them. Our reports are structured so the technical service can trace each tested attack path to the Annex 5 threat and the mitigation claim it challenges, without a translation step.
- Written authorisation before any testing. German criminal law (§202a StGB and related provisions) penalises unauthorised access to protected data, so testing never starts without a signed authorisation and rules of engagement from the system owner — targets, interfaces, windows and escalation. That document also defines exactly what the findings cover, which assessors need to see.
- TISAX-governed data exchange. German OEMs and many Tier-1s require a TISAX assessment label before sharing sensitive development data. Where your programme applies those rules, we agree the exchange mechanism and handling boundaries with your information-security team up front; our own operations run under ISO/IEC 27001:2022.
- NIS2 and the CRA around the vehicle. Germany's NIS2 implementation has applied since 6 December 2025 and treats medium-sized and larger motor-vehicle and parts manufacturers as important entities; its obligations cover the company's own networks, production systems and supply chain, which vehicle pentesting does not substitute for. The Cyber Resilience Act reaches charging equipment, aftermarket devices and tools that type approval does not — we test those alongside the vehicle programme.
Primary sources: Regulation (EU) 2019/2144, Cyber Resilience Act (EU) 2024/2847, Delegated Regulation (EU) 2025/1455, §202a StGB. For how R155, R156, ISO/SAE 21434, the CRA, NIS2 and TISAX fit together, see the automotive cybersecurity regulations map.
Scope
ECU, SDV and Vehicle Penetration Testing Scope
The full method — reconnaissance, hardware and protocol analysis, exploitation, reporting — is on our automotive penetration testing services page, as are the three levels we test at — component, ECU and vehicle. These are the targets where European programmes carry the most risk today.
ECU penetration testing — gateways and domain controllers
Debug ports, firmware extraction, UDS and DoIP diagnostics, Secure Boot and Secure Onboard Communication — scoped from the R155 risk assessment so the evidence lands against the Annex 5 threats the technical service will ask about.
Software-defined vehicle and high-performance compute stacks
AUTOSAR Adaptive services, SOME/IP and DoIP, hypervisor and container boundaries, service-oriented communication between zones, and the update and orchestration paths that make the platform software-defined. These are the surfaces European platforms are adding fastest, with the least published attack history.
Telematics, OTA and backend
Telematics units and their cellular and backend sessions, OTA update pipelines governed by R156, and the trust relationship back into the vehicle — the remote path that turns one flaw into a fleet-scale recall.
Infotainment, digital keys and V2X
Infotainment heads and their USB, Bluetooth and Wi-Fi surfaces; phone-as-a-key and passive keyless entry, including relay and UWB ranging attacks; and V2X stacks — IEEE 1609.2 and ETSI ITS-G5 certificate validation, replay protection and pseudonym handling, not just signal injection on the radio link.
EV charging interfaces and L-category platforms
ISO 15118 charging communication and Plug & Charge on the vehicle side; OCPP and the charger itself where it falls under the CRA; and the BLE keys, app connectivity and clusters of the two- and three-wheeler platforms that come under R155 from December 2027.
Process
How an Automotive Penetration Test Runs — Five Steps
The same five-step procedure runs on every engagement, wherever the bench is. It follows ISO/SAE 21434 verification and validation (Clauses 10 and 11) and produces the testing evidence UNECE R155 paragraph 7.3.6 and AIS 189 expect. Durations are typical for a single-ECU, grey-box scope; vehicle-level scopes extend step 3. Regional logistics — shipping, on-site work, contracting — are in the practicalities table below.
Scoping and NDA Week 1
Targets, interfaces and the assessment milestone the evidence is for. Access model agreed — black-, grey- or white-box. Mutual NDA on your template or ours.
Rules of engagement, TARA alignment and bench access Weeks 1–2
Signed authorisation and rules of engagement from the system owner. Review of your TARA extract or threat list so testing targets the attack paths that carry risk. Hardware to the lab, or the team on your bench.
Test execution Weeks 2–7 for one ECU
Hardware interfaces and firmware, UDS and DoIP diagnostics, in-vehicle networks, Secure Boot and Secure Onboard Communication, wireless and backend — with protocol fuzzing instrumented on the bench. Critical findings escalated as they are confirmed.
Report and findings walkthrough Week after execution
Every finding with reproducible steps, evidence, severity, attack-feasibility input per ISO/SAE 21434 Clause 15 and remediation guidance, mapped to the applicable threat catalogue — UNECE R155 Annex 5 or AIS 189 — and to ISO/SAE 21434 Clauses 10 and 11. Walked through live with your engineers.
Retest and closure evidence 1–2 weeks after your fixes
Re-execution against remediated firmware, a retest report and closure evidence filed in the structure your Cybersecurity Case already uses.
Checklist
What to Have Ready Before Scoping
None of these block the first call, but having them shortens the gap between scoping and the first finding.
- Sample units — ideally two, one with debug unlocked — and a shipping or remote-access decision
- Firmware builds under test, plus the flashing procedure
- Interface list: DBC, ARXML or an equivalent signal and diagnostics description
- TARA extract for the item, or the OEM's threat list if you are a supplier
- Bench harness, power supply and any gateway or peer ECUs needed to bring the unit up
- Schematics and design documents for grey- or white-box scope
- Your technical-service or OEM assessment date, so the retest lands before it
Applicability
Which Regime Applies to What You Are Testing?
Four instruments reach an automotive product-security team in Europe. Only one of them is satisfied by a vehicle pentest; the others shape what else the evidence has to show.
| What you are testing | Regime | Who carries the obligation | What testing evidence looks like |
|---|---|---|---|
| Complete vehicle (M, N and, from 2027, L categories) | UN R155 / R156 via Regulation (EU) 2019/2144 | The OEM, at type approval | Testing of the implemented security measures mapped to the Annex 5 threats considered in the risk assessment; retest and closure in the Cybersecurity Case |
| Component supplied to an OEM (ECU, TCU, charger controller) | ISO/SAE 21434 Clause 7 — Cybersecurity Interface Agreement under the OEM's R155 obligation | The supplier, as agreed in the CIA | Component-level verification and penetration-test report packaged against the CIA work split |
| EV charger or wallbox, aftermarket OBD or telematics dongle, diagnostic tool | EU Cyber Resilience Act — Regulation (EU) 2024/2847 | The manufacturer placing the product on the EU market | Vulnerability handling and security testing evidence for the product's conformity assessment |
| The manufacturer's own networks, production systems and supply chain | NIS2 — in Germany the NIS2UmsuCG, in force since 6 December 2025 | The company, as an important entity above the size threshold | Enterprise risk-management measures; vehicle penetration testing does not substitute for them |
Practicalities
Engagement Practicalities for Germany and Europe
The questions procurement, legal and programme managers ask before the scoping call, answered up front.
| Delivery model | Remote-first from the Agnile lab in Bengaluru — hardware shipped (export-control and customs checked with your trade-compliance team first) or secured remote bench access — with on-site phases at your facility in Germany or elsewhere in Europe for scoping, hardware work and retest, planned four to six weeks ahead to cover visa lead time |
|---|---|
| Working window | India is 4.5 hours ahead of CET and 3.5 hours ahead of CEST; your morning is our afternoon, and bench work continues after your day ends |
| Authorisation | Signed authorisation and rules of engagement from the system owner before any testing — the §202a StGB point, handled up front |
| Contracting | Agnile Technologies Private Limited; governing law and currency agreed per contract; mutual NDA before scoping |
| Data protection | Personal data in logs or VIN-linked artefacts is minimised and handled under a data-processing agreement you provide; operations run under Agnile's ISO/IEC 27001:2022 ISMS; TISAX exchange rules agreed with your security team |
| Language | Deliverables and walkthroughs in English |
| Approach | Grey-box by default; black-box or white-box by scope |
| Typical duration | 4–10 weeks per ECU plus shipping or access setup; 12+ weeks vehicle-level |
| Cost drivers | Targets and interfaces, box colour, sample units available, on-site days in Europe, retest rounds — fixed price after scoping |
| Deliverables | Findings report, Annex 5 and ISO/SAE 21434 mapping, attack-feasibility input for the TARA, retest report and closure evidence, executive summary |
Engagement models — component assessment, programme retainer, pre-assessment validation — are described on the services page. Running the engineering centre in India? See automotive penetration testing in India.
Why Agnile
Built for the Technical Service’s Reading, Not Just the Finding
- Evidence in the assessor's structure. Findings are mapped to R155 Annex 5 and ISO/SAE 21434 Clauses 10, 11 and 15 from the first draft, so nothing has to be translated before the technical service reads it.
- Engineering depth, not a checklist. The same engineers write Secure Boot chains, integrate Hardware Security Modules and ship AUTOSAR Classic and Adaptive security stacks, so the test starts from how the stack was actually built.
- A shared morning, every day. Remote-first delivery with on-site phases in Europe, live escalation in your working hours, and bench work that continues after your day ends.
- Certified operations. Agnile is ISO 9001:2015 and ISO/IEC 27001:2022 certified; firmware, schematics and findings are handled under an audited information-security system.
Penetration testing sits inside our wider automotive cybersecurity practice. Programmes that need the surrounding process — TARA, CSMS evidence, Interface Agreements — pair it with ISO/SAE 21434 consulting.
FAQ
Automotive Penetration Testing in Germany and Europe — Questions
Explore next
Plan the test around your programme
The service overview and methodology, the compliance hubs the evidence maps to, and the regulations map for Europe.
Penetration Testing
Scope Your Penetration Test in Europe
A short scoping call in your morning: bring your target ECU, your bench location and your type-approval or OEM assessment date. We respond to qualified enquiries within one business day.