Automotive
A vehicle is a network of computers that stays on the road for well over a decade. We test it that way — from the ECU to the cloud — and deliver evidence a type-approval authority can use.
Book a ConsultationLong-lived, networked, and now regulated
A modern vehicle carries dozens of electronic control units, several radios, a telematics link to the manufacturer’s cloud, and a phone app that can unlock it. All of it is attack surface, and much of it ships with keys, firmware and back-end services that have to stay trustworthy for as long as the vehicle is on the road.
In most major markets, though not the United States, cybersecurity is now a condition of type approval. UN Regulation No. 155 requires the manufacturer to show appropriate and sufficient testing of a vehicle type’s cybersecurity — but it never says what that testing is. It sets no method, depth, tooling or scope, and the words “penetration testing” do not appear in it. Our job is to make your definition of “sufficient” one you can defend to the technical service that assesses it.
Our three services meet in the same places on a vehicle. The key that signs an over-the-air update is a penetration-testing target today and a post-quantum problem before the car retires. The voice assistant in the dashboard is an AI system with a path to vehicle functions. One team, one scope, one body of evidence.
Three services, tuned to the vehicle
Artificial Intelligence Security (AI-BOM)
In-car voice assistants and agents that can reach vehicle functions, AI features in connected-car apps, and the pipelines that deliver driver-assistance models: over-the-air model delivery, calibration-file integrity, and what the car does when a sensor is disabled. We test the pipeline, not just the model.
Learn more →Post-Quantum Cryptography Readiness (CBOM)
A cryptographic inventory of the vehicle and its back end: secure boot and over-the-air update signing, ECU key provisioning, V2X and Plug & Charge certificates, and the TLS links to your cloud. A key fused into an ECU at the factory has to outlive the car, so crypto-agility is a design decision — not something to fix in a recall.
Learn more →Product Penetration Testing
In-vehicle networks and diagnostics — CAN, automotive Ethernet, UDS and DoIP — gateways and ECUs, keyless entry, telematics, infotainment, the vehicle side of EV charging, and the mobile apps, dealer portals and cloud APIs that can command the car. Structured as R155 test evidence and focused on the high-risk paths in your threat analysis.
Learn more →Built for vehicles, not adapted from IT
Bench first
Documentation review and software-only testing find the cheapest bugs; an integrated bench or hardware-in-the-loop rig is where most of the value is. Most engagements never need a moving vehicle — and we’ll tell you if yours doesn’t.
Rated on damage, not CVSS
Safety, financial, operational and privacy impact are rated separately and weighed against attack feasibility, in the ISO/SAE 21434 vocabulary your engineers and assessors already use. “Requires physical access” is weak comfort when an attacker can buy the same car.
Safety findings escalate immediately
Any path to unintended actuation is flagged the moment we find it — not at report time — and routed to your product security and functional-safety teams together.
Fixes grouped by how they ship
Remediation is sorted by delivery route — back end, over-the-air, service-visit reflash, next production run, next hardware revision — because that decides how much of the fleet a fix actually reaches.
Where the rules stand, market by market
There is no single global deadline — each market applies its own instrument on its own dates. Current as of October 2026.
| Market | Instrument | What it means for you |
|---|---|---|
| UN (1958 Agreement) | UN R155 — cybersecurity management system and vehicle type UN R156 — software update management | R155 para 7.3.6: the manufacturer “shall perform, prior to type approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented.” What was tested and the outcome go in the type-approval file (Annex 1, item 9.7). No test method is prescribed — that is yours to define and defend. |
| European Union | R155 via Reg (EU) 2019/2144 R156 via Reg (EU) 2018/858 | R155 has been required to register any new car, van, truck or bus (categories M and N) since 7 July 2024. R156 has applied to all new complete vehicles, trailers included, since 7 July 2026; multi-stage vehicles follow on 7 July 2029. |
| United Kingdom (GB) | SI 2025/1110 | R155 and R156 have been required for new GB vehicle types since 1 June 2026, and apply to registration of all new complete vehicles from 1 June 2027. |
| Japan | R155 and R156 under national rules (MLIT) | Phased in by update capability: vehicles with over-the-air updates since July 2022 for new models and July 2024 for all; vehicles without, since January 2024 and May 2026. |
| China | GB 44495-2024 — vehicle cybersecurity GB 44496-2024 — software updates | Mandatory national standards, each since amended (Amendment No. 1). They have applied to new vehicle types since 2026 and apply to types already in production from January 2028. Developed alongside R155 but not equivalent to it: an R155 certificate does not satisfy them, and GB 44495 adds data-security requirements. |
| United States | No federal cybersecurity standard 15 CFR 791, subpart D (BIS) | The US is not party to the 1958 Agreement, no FMVSS covers cybersecurity, and NHTSA’s 2022 best practices are non-binding. The binding rule is about the supply chain: connected-vehicle software linked to China or Russia is prohibited from model year 2027, hardware from model year 2030. Vehicles over 10,000 lb gross weight are excluded. |
| EU products outside type approval | Cyber Resilience Act — Reg (EU) 2024/2847 | Does not apply to vehicles covered by Reg (EU) 2019/2144, but does reach connected products that sit outside vehicle type approval, such as EV chargers. Manufacturers’ reporting of actively exploited vulnerabilities and severe incidents since 11 September 2026; full application from 11 December 2027. |
| V2X (Europe) | ETSI TR 103 971-1 V2.1.1 (May 2026), technical report | ETSI’s risk analysis for connected road transport states that every V2X station will have to be quantum-safe; as a technical report, it treats that as indicative until ratified in an ETSI Technical Specification. Today’s V2X messages carry ECDSA signatures of about 64 bytes; the NIST post-quantum signatures it assesses range from 666 bytes (Falcon, not yet a NIST standard) through 2,420 (ML-DSA) to 7,856 and more (SLH-DSA) — a bandwidth problem as much as a cryptographic one. |
| Engineering standard | ISO/SAE 21434:2021 | The road-vehicle cybersecurity engineering standard — voluntary, and named in R155 only as an example — and the vocabulary we report in: damage scenarios, attack paths, attack feasibility. The 2021 edition is still current; ISO marked it for revision on 2 October 2026, and a new edition is in development. |
What you get
- R155 test evidence — what was tested, how, and the outcome, organized around the high-risk paths in your threat analysis and ready for the type-approval file (Annex 1, item 9.7)
- Risk-rated findings report — damage and attack feasibility rated separately, with remediation grouped by delivery route and reproduction steps your engineers can work from
- Cryptographic bill of materials — vehicle and back-end cryptography in CycloneDX format, with a post-quantum migration roadmap sequenced against your vehicle programmes
- AI bill of materials — every model, prompt, tool and data source behind your in-vehicle and connected AI features, delivered as a CycloneDX ML-BOM
- Retest of fixes — evidence that remediation landed, for the file and for your own release gates
Make “sufficient testing” something you can defend.
An automotive engagement starts with your vehicle architecture, your threat analysis, and the markets you sell into.
Get in Touch