Type-approve the vehicle.
Ship the OTA. Survive the charger.

Yes — they cover different scopes. ISO 27001 is the corporate information-security management system (ISMS) baseline. TISAX (Trusted Information Security Assessment Exchange, governed by ENX e.V.) is the VDA-derived audit scheme that OEMs use to bind their suppliers to a common information-security level — TISAX assessment levels AL1, AL2 or AL3, with information-security, prototype-protection and data-protection objectives. ISO/SAE 21434 is the standard for road-vehicle cybersecurity engineering: it mandates a Cybersecurity Management System (CSMS) covering the entire product lifecycle — concept, product development, post-development (production, operation, maintenance, decommissioning) — and is the technical evidence base that UNECE WP.29 R155 type-approval auditors expect. An OEM going to market in any of the 64 UNECE 1958 Agreement contracting parties (the EU, the UK, Japan, South Korea and most others, but not the US, China or India) cannot type-approve a new vehicle architecture in 2024 onward without a valid R155 CSMS certificate, and the technical substance of that certificate is ISO/SAE 21434 conformance. TISAX is the supplier-tier hygiene layer underneath. The three are complementary, not overlapping.

Active CAN-bus testing is never performed on a vehicle that will be returned to a customer or used in further type-approval testing. The default rig is an engineering mule or a hardware-in-the-loop (HIL) bench supplied by the OEM's vehicle cybersecurity team, with a documented baseline ECU configuration that can be reflashed in minutes. Test surfaces include the OBD-II port (UDS / ISO 14229 diagnostic services, Security Access 0x27 brute force, routine control 0x31 abuse), the central gateway, the body and chassis CAN segments, and any exposed CAN-FD or automotive Ethernet (100/1000BASE-T1, SOME/IP) backbones. Findings are reproduced on bench, not on the road. Rules of Engagement explicitly exclude anything that could disable a safety-critical ECU (airbag, ESP, braking, steering, ADAS sensor fusion) on a vehicle that might return to public use. The deliverable supports the R155 type-approval cybersecurity assessment without exposing a production vehicle to destructive testing.

UNECE WP.29 R155 covers the Cybersecurity Management System and the cybersecurity engineering of the vehicle type. UNECE WP.29 R156 covers the Software Update Management System (SUMS) and the technical security of the over-the-air update process itself — manifest integrity, package signing and chain of trust, rollback prevention, A/B partition handling, dependency tracking across ECUs, driver consent and notification, and the ability to abort a failed update without bricking the vehicle. R156 also defines RxSWIN (Regulation X Software Identification Number) so type-approval authorities can pin a specific software baseline to a specific vehicle homologation. OTA pentesting therefore exercises both the back-end update server (authentication, authorisation, tenant isolation across vehicle fleets, signing-key custody) and the in-vehicle update client (signature verification bypass, downgrade attacks, manifest tampering, partial-update interruption, secure-boot continuity). The deliverable maps each finding to the R156 SUMS requirement it threatens.

Four surfaces. (1) The OCPP (Open Charge Point Protocol) link between charger and back-end — OCPP 1.6-J is still widely deployed but lacks transport security guarantees on its own; OCPP 2.0.1 adds security profile 3 (mutual TLS with client certificates) which is the target end-state. We test OCPP authentication, message-injection (RemoteStartTransaction, RemoteStopTransaction, ChangeConfiguration), tariff and meter-value tampering, firmware-update message abuse, and tenant isolation across CPO back-ends. (2) ISO 15118 — Plug & Charge — covering the EV-to-EVSE V2G_CI handshake, certificate provisioning, Mobility Operator (MO) contract handling, and the PKI underpinning all of it. (3) The HMI and payment surface — RFID and NFC card cloning, contactless EMV abuse, QR-code redirect, billing-fraud through transaction-meter manipulation. (4) The physical and serial-bus surface — exposed Ethernet ports, debug headers, J1939 / CAN-FD on DC fast chargers, and the supervisor-controller boundary. Findings tie back to the ENISA EV-charging threat landscape report and the NIST IR 8473 EV-extreme-fast-charging cybersecurity framework.

OEMs flow ISO/SAE 21434 obligations down to their Tier-1 suppliers (and Tier-1s to Tier-2 component vendors) via a Cybersecurity Interface Agreement (CIA) — a contractual artefact required by Clause 7 of ISO/SAE 21434. The supplier is then expected to evidence CSMS-equivalent practice for its scope, typically via a TISAX assessment at the appropriate level (AL2 or AL3 for prototype data or higher-criticality components). AxVeil engagements for Tier-1 suppliers cover the technical pentest of the delivered ECU or system (UDS service surface, secure-boot chain, JTAG / SWD lockdown, debug-port closure on production silicon, supply-chain integrity of the bootloader and application binaries) and the evidence pack that the OEM's vehicle cybersecurity team needs to fold into its own R155 type-approval submission. We provide the CIA-aligned findings appendix so the supplier's account manager does not have to re-derive it under deadline pressure.