The US Commerce Department’s connected-vehicle rule has been in force since 17 March 2025. Software prohibitions begin with Model Year 2027 and hardware prohibitions with Model Year 2030, and covered importers and manufacturers have to file a Declaration of Conformity every year (BIS). Then in August 2026, CISA put out advisory ICSA-26-216-01 on KARR alarm systems installed in at least two million vehicles, where every unit relied on a single Bluetooth authentication key (CVE-2026-18411). And here is where ISO 21434 Compliance comes into play.
ISO/SAE 21434 wasn’t required by either event, but the fallout lands on the people who build and test vehicle software anyway. OEM customers still ask US suppliers for ISO 21434 evidence, since UNECE R155 has applied to every new vehicle in its markets since July 2024. What follows is a clause map, a method for testing each interface, a finding template and a crosswalk that connects results to work products.
Teams preparing for an audit can speak with a Qualysec automotive security expert about scope and evidence!
What Does ISO 21434 Compliance Actually Mean?
ISO/SAE 21434:2021 is a voluntary engineering standard, published by ISO and SAE International in August 2021. Being in ISO 21434 Compliance means delivering the work products and satisfying the requirements it sets out for electrical and electronic systems in road vehicles. The standard doesn’t issue certificates. Evidence comes from security audits and assessments, and ISO/PAS 5112 gives guidelines for auditing cybersecurity engineering.
Three things get mixed up here in the ISO 21434 standard. The standard describes a process. R155, by contrast, is a regulation: it gives a manufacturer a CSMS certificate valid for up to three years. Testing the product underpins both, since it generates evidence that either one can draw on.
Which Automotive Cybersecurity Standards Matter in the US?
No US rule requires ISO/SAE 21434. What pushes suppliers is OEM contracts, exports into R155 markets, and the Commerce rule. These standards overlap quite a bit, so the table below sorts the binding ones from the merely advisory.
| Standard or rule | Scope | US status | Link to ISO/SAE 21434 |
| ISO/SAE 21434:2021 | Cybersecurity engineering across the vehicle lifecycle | Voluntary | Core process standard |
| UNECE R155 | CSMS and type approval | Binding in UNECE markets, reaches US suppliers through OEMs | CSMS often built on it |
| UNECE R156 | Software update management | Same as R155 | Related to ISO 24089 |
| ISO 24089 | Software update engineering | Voluntary | Supports R156 evidence |
| ISO/PAS 5112 | Auditing cybersecurity engineering | Voluntary | Audit guidance |
| ISO/SAE TR 8477 | Verification and validation | Informative | Planned to merge into edition 2 |
| NHTSA best practices (2022) | Vehicle cybersecurity for safety | Non-binding | Shared themes |
| Commerce connected-vehicle rule | VCS hardware and ADS software, PRC or Russia nexus | Binding from 17 March 2025 | None, it’s a supply-chain rule |
A second edition of ISO/SAE 21434 hasn’t started yet. According to a 2025 working-group presentation on cybersecurity automotive standards, work on it should start in 2026 and take over three years, with TR 8477 folded in (GlobalPlatform).
What Does ISO 21434 Require, Clause by Clause?
The first four clauses of ISO 21434 compliance deal with scope, references, terminology and general considerations. Clauses 5 to 15 carry the requirements, and each one gives a tester something to anchor to.
| Clause | Topic | Evidence | Test relevance |
| 5 | Organizational cybersecurity management | Policy, process definitions | Sets who owns testing and sign-off |
| 6 | Project-dependent management | Cybersecurity plan | Places test activities in the schedule |
| 7 | Distributed activities | Supplier interface agreement | Says which party tests which component |
| 8 | Continual activities | Monitoring, vulnerability analysis | Triggers retests when a component CVE appears |
| 9 | Concept | Item definition, TARA, goals | Source of test targets |
| 10 | Product development | Specifications, verification results | Component tests, fuzzing, static analysis |
| 11 | Cybersecurity validation | Validation report | Penetration testing against goals |
| 12 | Production | Production control | Debug access and keys locked at end of line |
| 13 | Operations and maintenance | Incident response, update records | Retest after each update |
| 14 | End of support, decommissioning | Support-end communication | Data and key wipe checks |
| 15 | TARA methods | Threat, impact, feasibility, risk | Prioritizes test cases |
How Do You Build a TARA That Testing Can Verify?
Clause 15 of ISO 21434 compliance walks from assets to a treatment decision: asset identification, threat scenarios, impact rating, attack paths, attack feasibility, risk value, and finally the choice to reduce, avoid, share or retain the risk. A TARA row that can’t be traced to a test is only a claim. One that carries a goal and a test case ID is evidence. CAL, the assurance level that sets how rigorous a test has to be, comes from an example method in an annex of the standard.
How Do You Test a Vehicle System Interface by Interface?
One loop works for every interface. Write down how the unit behaves before you touch it. Then change just one thing, an input or an access condition, and see whether the same function opens up through a different door. Log whatever you find with proof, and come back after the patch to do it once more. These checks also support TISAX compliance by helping demonstrate automotive cybersecurity controls and security testing evidence.
1. Telematics and the cellular side
Set the unit up on a bench with a test SIM and let it register. What it exposes after that is your baseline. Next come port scans, a hunt for AT commands or diagnostic interfaces hiding behind the modem, and a few malformed commands thrown at the backend connection. If the unit is built right, nothing answers without authentication, and a backend with a bad certificate gets turned away. Keep the port scans, the packet captures and any firmware strings you pull out, since they make up the evidence.
2. Bluetooth, Wi-Fi and the head unit
Pairing comes first. Try pairing with no confirmation from the user. Record some commands, then replay them from a different device. Compare credentials across several units to see whether they match. Every unit ought to authenticate on its own, and a default password on the access point is a failure all by itself. The worst case is a single key, extracted once from an app or a firmware image, that works on every unit built.
3. CAN, Automotive Ethernet and gateway behavior
CAN doesn’t authenticate senders, so the gateway’s segmentation does the protecting. Inject diagnostic and powertrain frames from the telematics side or the OBD port, and watch what the gateway lets through. Services on Automotive Ethernet, including SOME/IP and DoIP, get the same treatment. The gateway should drop frames that don’t belong on the destination bus, and bus logs from both sides prove it.
4. UDS, OBD and flashing
Diagnostic access mostly goes through UDS, so work down its services one at a time. Open a session with DiagnosticSessionControl (0x10). SecurityAccess (0x27) comes next, the seed-and-key exchange. A flash begins with RequestDownload (0x34) and TransferData (0x36). Look at how random the seed really is. Fail the key a few times and see if the ECU locks you out. Then offer it an unsigned image. Each of those should be refused, and the whole session transcript should be saved.
5. Secure boot, debug ports and key storage
This part is done on the board. Try JTAG or SWD, plug into the UART console, boot a modified image, and flash an older firmware back on. On production units the debug ports should be locked (that’s the link to clause 12), and the boot chain has to refuse any image that isn’t validly signed. Photos of probed pads and the console output serve as evidence.
6. OTA update client and backend
An update package passes through the backend, the vehicle’s client and the target ECU, and each hop gets tested. Three attempts: tamper with a package, replay an older one, and ask for an update for a vehicle that the account doesn’t own. The first two should hit signature checks and rollback protection, while authorization should block the third. Because UNECE R156 and ISO 24089 cover this pipeline, keep the rejection logs.
7. Mobile app and cloud APIs
Vehicle apps and backends usually address a car by VIN. The tester swaps one VIN for another under a valid session, inspects tokens, and pulls the app apart looking for embedded keys. Another owner’s vehicle should return a refusal, and no static secret should sit in the package. Request and response pairs are the evidence.
Which Test Methods Does ISO/SAE 21434 Allow?
It’s rare for automotive cybersecurity standards to prescribe a single method. ISO 21434 lets Clause 10 verification rely on static analysis (RQ-10-10) and recommends component testing (RC-10-12). Fuzzing, plus vulnerability scanning with software composition analysis, handles unknown and known flaws in CAN, Automotive Ethernet, and Bluetooth stacks. Clause 11 of ISO 21434 Compliance is where penetration testing fits. Requirement RQ-11-01 allows it as a validation activity that demonstrates the cybersecurity goals were met (Black Duck).
Worked Example: A Shared Bluetooth Key in 2.2 Million Vehicles
CISA advisory ICSA-26-216-01 covers the Acrisure KARR BT and DR-100, dealer-installed anti-theft systems. NVD published CVE-2026-18411 on 5 August 2026 as CWE-321, using a hard-coded cryptographic key. It carries a CVSS v3.1 score of 8.1 with an adjacent-network attack vector. Versions dated before 20 July 2026 are vulnerable.
Researchers at the University of California, San Diego reverse-engineered the official app and pulled out the single key shared by every unit. Armed with that key, an attacker in Bluetooth range could lock or unlock the doors, silence the alarm, and keep the engine from starting (Popular Science). The flaw couldn’t drive the car. The researchers disclosed it in January 2025, and Acrisure released a patch on 20 July 2026.
Mapped to the standard, the Bluetooth interface is a threat scenario in clause 15 with a short attack path, since the key sits in a public app. Clause 10 should have produced a requirement for unique per-device keys. A Clause 11 penetration test of the app and the radio link would have found the shared key. Clause 7 matters too, because a third-party device needs a clear interface agreement. A TARA that leaves dealer-installed hardware out doesn’t remove it from the threat model, and no OEM recall reaches it either.
Organizations that want this kind of mapping applied to their own interfaces can book a scoping call with Qualysec!
What Should an Automotive Cybersecurity Finding Include?
A finding for compliance should let an engineer and an auditor follow the same trail from threat to fix. This template does it.
- ID, item or component
- TARA threat ID, cybersecurity goal, CAL
- Interface and preconditions
- Steps
- Expected vs observed
- Evidence
- Severity and attack feasibility
- Remediation owner
- Work product affected, R155 relevance
- Retest status
How Do Test Results Map to ISO/SAE 21434 Work Products and R155 Evidence?
Map findings to work products
A penetration test feeds validation and vulnerability management. It doesn’t replace the CSMS, and it doesn’t replace the TARA either.
| Finding | Clause | Work product | Evidence | Retest evidence |
| One key accepted by every unit | 11 | Validation report, TARA update | App teardown, command log | Per-device key accepted only |
| Debug port open on production unit | 12 | Production control | Console log | End-of-line check |
| Unsigned update accepted | 10, 13 | Verification report, update records | Package, ECU log | Rejection log |
| Gateway forwards diagnostic frames | 10 | Verification report | Bus capture | Clean capture |
Map findings to UNECE R155 and US rules
R155 requires each vehicle type’s threat analysis to cover the threats in its Annex 5, and the manufacturer holds the CSMS certificate. Findings from testing support that file. NHTSA’s 2022 best practices are non-binding. The Commerce rule restricts hardware and software supply chains, so test findings don’t map to it, and “no direct mapping” is the right entry.
When Should Teams Test?
Whatever cybersecurity automotive standard applies, testing is triggered by lifecycle events rather than dates on a calendar. That means testing during concept validation, ahead of start of production, after every OTA release, after any supplier or component change, and on a monitoring cycle once vehicles are on the road. Clause 8 and clause 13 expect that last step.
How Qualysec Helps Automotive Teams
Qualysec produces evidence for a cybersecurity automotive standard such as ISO/SAE 21434. Its automotive device penetration testing and IoT penetration testing pages describe the wider scope.
Embedded and ECU Penetration Testing
Qualysec tests ECUs on a bench from supplied firmware images, and it covers CAN injection, telematics units, and Bluetooth, Wi-Fi and USB interfaces.
Connected Vehicle Backend, API and Mobile App Testing
The OTA pipeline is tested from backend server to ECU acceptance, and backend APIs can be tested without a physical vehicle. Companion mobile apps fall under Qualysec’s mobile application testing.
TARA-Linked Reporting, Retesting and Evidence Support
Qualysec can conduct or review a TARA before testing and aim testing at the highest-risk attack paths. Reports carry a compliance mapping section, and retesting is included.
Conclusion
Both events in the introduction came from gaps that nobody tested on purpose: a shared key in a companion app, and supply chains that nobody had mapped. Tying each interface test to a clause, a TARA threat, and a work product is what turns a pentest into ISO 21434 compliance audit evidence. That tie is what a team needs when an OEM asks for proof.
Ready to map your vehicle systems to the standard of ISO 21434 Compliance? Discuss your interfaces, TARA and audit needs with Qualysec.
FAQs
1. Does the US require ISO/SAE 21434?
No federal rule requires it. NHTSA’s 2022 best practices aren’t binding, and the Commerce connected-vehicle rule restricts supply chains rather than setting engineering requirements. The demand comes from OEM contracts and R155 markets, so suppliers continue to treat the ISO 21434 standard as the baseline their customers audit against.
2. How does ISO/SAE 21434 relate to UNECE R155?
R155 is a regulation that requires a certified CSMS for type approval in UNECE markets. ISO/SAE 21434 is a voluntary standard that most manufacturers and suppliers use to build that CSMS, and its work products, such as the TARA, serve as audit evidence. Conforming to it supports R155 compliance, but it doesn’t replace the certificate or approval.
3. Is penetration testing enough for ISO/SAE 21434?
Not by itself. RQ-11-01 permits penetration testing as a validation activity, yet the standard also expects a TARA, clause 10 verification, clause 8 vulnerability management and the organizational processes in clause 5. A pentest report supplies one work product in that chain, and auditors will look for the rest of it.
4. What is the difference between TARA and a pentest?
A TARA is an analysis done on paper. It catalogs assets, threats, and attack paths and then rates the risk. A pentest runs those attack paths against real hardware or software and logs the outcome. Both are needed under automotive cyber security standards: the TARA decides what gets tested, and the pentest shows if the planned controls hold up.
5. What Is CAL, and How Does It Change Testing?
CAL means cybersecurity assurance level, and the standard defines it from CAL 1 up to CAL 4. A higher level calls for more rigorous verification and validation, so it changes how deep and how independent the testing has to be. The annex example gives one way to derive it, and the project’s agreed method decides the result.
6. How often should connected vehicle systems be retested?
After every fix, since a patch can close one path and leave another open. Retesting also follows each OTA release, any supplier or component change, and a published CVE in a component the vehicle uses. After launch, clause 8 monitoring decides the cycle, and the KARR advisory shows how long a flaw can sit between disclosure and patch.
