What we deliver
Cybersecurity test specification
Test cases derived from the TARA, cybersecurity goals and requirements, with attack paths mapped to tests and pass criteria.
Fuzz testing
Protocol fuzzing of CAN, UDS, SOME/IP, DoIP, Bluetooth and Wi-Fi interfaces, and white-box fuzzing of parsers with AFL++ or libFuzzer. See fuzz testing.
Penetration testing
Time-boxed attacks on ECUs, gateways and telematics units: debug ports, bootloaders, diagnostic access, secure boot, key storage and backend interfaces.
Vulnerability scanning
SBOM generation, matching components against CVE data, network and service scans, and triage of findings by exploitability.
Security function tests
Verification of SecOC, secure boot, secure diagnostics (UDS services 0x27 and 0x29), firewall rules and update signature checks.
Findings and retest
Findings rated by risk, tracked to closure with developers and retested, so the evidence shows the fix as well as the finding.
Regulations, standards and test evidence
| Requirement | Applies to | Test evidence typically expected |
|---|---|---|
| UNECE R155 | Vehicle types under UNECE type approval; in the EU, all new vehicles since July 2024 | Testing that verifies the effectiveness of cybersecurity measures per vehicle type, linked to the risk assessment |
| ISO/SAE 21434 | Road-vehicle E/E systems across the supply chain | Cybersecurity verification and validation reports, including vulnerability testing such as fuzzing and penetration testing |
| IEC 62443-4-2 (with 4-1) | Industrial automation and control system components | Security functional tests and vulnerability testing against the target security level |
| EU Cyber Resilience Act | Products with digital elements on the EU market | Vulnerability and incident reporting from 11 Sep 2026; essential requirements, vulnerability handling and SBOM from 11 Dec 2027 |
How we work
01
Scope
Agree targets, interfaces, test depth (black, grey or white box) and rules of engagement, using your TARA where one exists.
02
Prepare
Set up benches, restbus and access, collect firmware images and SBOMs, and write the test specification.
03
Test
Run fuzzing campaigns, penetration tests and scans, logging every crash, anomaly and finding with reproduction steps.
04
Report
Rate findings, map them to cybersecurity goals and requirements, and agree fixes with developers.
05
Retest
Verify fixes and update the evidence for the cybersecurity case or technical file.
Where this fits
Testing follows threat analysis and design. For TARA, cybersecurity concepts and the cybersecurity case, see ISO/SAE 21434 cybersecurity and the UNECE R155 glossary entry. Embedded and industrial products covered by the CRA or IEC 62443 are tested alongside embedded software testing, and R156 update-chain tests are described on automotive testing.
Standards
Toolchains our engineers work with
- AFL++
- Burp Suite
- can-utils
- ChipWhisperer
- Defensics
- Lauterbach TRACE32
- libFuzzer
- Metasploit
- Nmap
- Scapy
- Syft
- Vector CANoe
- Wireshark
Related work
Case studies →Fuzz and penetration testing an industrial gateway for the Cyber Resilience Act and IEC 62443-4-2
A recurring security test cycle for an industrial gateway: fuzzing, penetration tests and SBOMs mapped to IEC 62443-4-2 and the CRA.
Planning MIL-STD-810H and MIL-STD-461 pre-compliance for an indigenised rugged subsystem
Tailoring MIL-STD-810H and 461 requirements, writing procedures, running pre-scans and preparing a rugged LRU for its accredited lab campaign.
Closing DO-178C structural coverage with independent verification for a DAL B component
Independent verification closes statement and decision coverage, coupling analysis and tool qualification for a DAL B software component.
Further reading
All insights →Building an engineering or test team for a mid-market GCC in India
Ramp waves, dedicated team vs Build-Operate-Transfer, governance and the measures that matter for a mid-market GCC's engineering or test team.
Euro NCAP 2026 ADAS Testing: What Changes for SIL/HIL Test Plans and Test Capacity
Euro NCAP 2026 multiplies ADAS test variations. How to restructure SIL/HIL plans around ISO 34502 and OpenSCENARIO, and plan the capacity.
Automotive Cybersecurity Penetration Testing for R155: Fuzzing, OTA and ISO/SAE 21434 Evidence
What R155, R156 and ISO/SAE 21434 test evidence suppliers need, and where fuzzing, penetration testing and OTA tests fit.
Frequently asked questions
Is fuzz testing mandatory under ISO/SAE 21434?
Not by name. ISO/SAE 21434 requires cybersecurity verification and validation with methods chosen and justified for the item, and names fuzz testing among the methods for finding vulnerabilities, alongside penetration testing and vulnerability scanning. In practice OEMs and type-approval assessors expect fuzzing of external and diagnostic interfaces, and it is the most discussed vehicle-level test method.
What does UNECE R155 require us to test?
R155 requires the manufacturer to verify, per vehicle type, that the cybersecurity measures identified through risk assessment are implemented and effective, through appropriate testing. Technical services typically look for a test specification linked to the TARA, functional security tests, penetration testing and fuzzing of attack surfaces, and evidence that findings were closed. Suppliers provide component-level evidence to the OEM.
What is the difference between penetration testing and fuzzing?
Fuzzing sends large volumes of malformed or unexpected inputs to an interface automatically and watches for crashes, hangs or wrong behaviour. Penetration testing is a skilled, goal-driven attempt to defeat security controls by chaining weaknesses, such as getting from a diagnostic port to code execution. Fuzzing scales and repeats well; penetration testing finds logic flaws fuzzers miss. Most programmes need both.
Should testing be black box, grey box or white box?
Grey and white box find more for the same effort, because testers can use source, firmware images, test keys and design documents. Black box reflects an outside attacker but spends much of its time on discovery. For R155 and ISO/SAE 21434 evidence, most programmes use grey box with defined access, plus white-box fuzzing of critical parsers.
Do the same methods work for industrial and IoT devices?
Yes. Fuzzing, penetration testing and SBOM-based vulnerability scanning apply equally to PLCs, gateways and IoT devices. IEC 62443-4-1 calls for security verification and validation testing, including vulnerability and penetration testing, for components assessed against IEC 62443-4-2. Under the EU Cyber Resilience Act, reporting duties apply from 11 September 2026 and most other obligations from 11 December 2027.
How are firmware, keys and findings handled?
Under the NDA and data-handling terms agreed at scoping, normally on your infrastructure or on isolated test systems. Findings are reported only to named contacts, and test artefacts are returned or deleted at the end of the engagement as agreed. Test keys rather than production keys are used wherever the test allows.
Can we hire automotive cybersecurity engineers instead?
Yes. We recruit security test, penetration testing and ISO/SAE 21434 engineers on contract, contract-to-hire or permanent terms. See hire automotive cybersecurity engineers for role profiles and how candidates are screened on fuzzing, penetration testing and TARA work.
Tell us your domain, standard and team size — get a scoped brief in 2 minutes.