Connected Vehicles

Automotive Cybersecurity Standards: A 2026 Compliance Guide

Explore the world of automotive cybersecurity standards and regulations. Learn how ISO/SAE 21434 & WP.29 are shaping secure, connected car tech.

Doc McConnell

Doc McConnell

Head of Policy and Compliance

February 4, 2026
TL;DR: Automotive cybersecurity standards are the rules that require carmakers and their suppliers to manage cyber risk across a vehicle's whole life. The big ones are UN R155 and UN R156, ISO/SAE 21434 and ISO 24089, and China's GB 44495 and GB 44496. They differ in the letter, but they share a spine: manage risk continuously, and prove it with evidence about what you actually shipped.

A modern car runs on connected software, takes updates over the air, and talks to the world around it. That makes it useful, and it makes it a target. Over the past few years, regulators turned what used to be optional good practice into hard requirements that decide whether a vehicle can be sold at all. This guide maps the standards that matter, shows how they compare, walks through audit prep, and looks at where the rules are heading.

What are automotive cybersecurity standards?

Automotive cybersecurity standards are the rules and frameworks requiring vehicle makers to manage cyber risk across a vehicle's lifecycle, from design through post-sale software updates.

Some are laws, some are voluntary engineering standards, and the two work together. A regulation usually says what you must achieve and ties it to market access. A standard usually says how to do the engineering well enough to prove it. The cyber security standards for the automotive industry have converged on a shared idea: security isn't a one-time test, it's a continuous process you have to evidence.

What are the key automotive cybersecurity standards and regulations?

The key automotive cybersecurity standards are UN R155 and UN R156, ISO/SAE 21434 and ISO 24089, and China's GB 44495 and GB 44496.

Each regulation has a matching engineering standard. UN R155 (cybersecurity) pairs with ISO/SAE 21434, and UN R156 (software updates) pairs with ISO 24089. China built its own mandatory equivalents. The United States takes a lighter, mostly voluntary approach. Here's the landscape at a glance.

Standard / regulationWhat it coversTypeWhere it applies
UN R155Cybersecurity, CSMS, vehicle type approvalMandatory regulationUNECE markets (EU, Japan, South Korea, and more)
UN R156Software updates, SUMSMandatory regulationUNECE markets
ISO/SAE 21434Cybersecurity engineering processVoluntary international standardGlobal
ISO 24089Software update engineeringVoluntary international standardGlobal
GB 44495-2024Vehicle cybersecurityMandatory national standardChina
GB 44496-2024Vehicle software updatesMandatory national standardChina
NHTSA Cybersecurity Best PracticesCybersecurity guidanceVoluntary guidanceUnited States

What is UN R155, and how does UNECE WP.29 work?

UN R155 is the UNECE regulation requiring a Cybersecurity Management System and vehicle type approval. Its companion UN R156 governs software updates.

Both came out of the UNECE World Forum for Harmonization of Vehicle Regulations, known as WP.29, and its working party on automated and connected vehicles (GRVA). They were adopted in 2020 and entered into force in 2021. In the European Union, the cybersecurity regulation became mandatory for all new vehicle types in July 2022 and for all new vehicles produced from July 2024. The rules apply across the WP.29 contracting parties, including the EU, Japan, and South Korea, though the United States and Canada are not bound by them. Our deep dive on the UN R155 regulation covers the approval process in more detail.

What is ISO/SAE 21434, the automotive cybersecurity standard?

ISO/SAE 21434 is the international standard for automotive cybersecurity engineering. It defines how to manage cyber risk across the lifecycle, and underpins UN R155 compliance.

UN R155 tells you what to achieve but stays technology-neutral on purpose. It doesn't hand you a recipe. ISO/SAE 21434 fills that gap with the engineering detail: governance, threat analysis and risk assessment (TARA), requirements, verification, and post-production monitoring. In practice, most OEMs use it as the backbone of how they show a regulator they've done the work. We break down how the ISO 21434 standard works and how to support it in a dedicated guide. The software-update equivalent, ISO 24089, plays the same role for UN R156.

What regional automotive cybersecurity regulations apply outside Europe?

Beyond Europe, China enforces mandatory standards GB 44495 and GB 44496, while the United States relies on NHTSA's voluntary guidance and the Connected Vehicle Rule.

China's standards took effect for new vehicle types on January 1, 2026 and function as a market gate: a non-compliant connected vehicle can't clear the approval needed to sell there. If you ship into that market, our China GB 44495 and GB 44496 compliance guide lays out the specifics. The U.S. picture is different. There's no single binding cybersecurity standard; instead there's NHTSA's voluntary best-practice guidance plus targeted rules, most notably the Commerce Department's restrictions on connected vehicle hardware and software from countries of concern.

What are the future trends in automotive cybersecurity for 2025 to 2030?

Through 2030, expect tighter enforcement, more software-defined vehicles, SBOM and supply-chain mandates, AI-driven threats, and standards converging on continuous, evidence-based proof.

The direction of travel is clear even where the details aren't settled. As vehicles become more software-defined, the attack surface grows and updates become constant, which pushes regulators toward continuous assurance instead of point-in-time certification. A few shifts worth planning for:

  • Software bills of materials become table stakes. Knowing every component in your firmware moves from nice-to-have to expected evidence.
  • Supply-chain scrutiny deepens. Tier 1 and Tier 2 suppliers carry more of the proof burden, not less.
  • AI cuts both ways. Attackers use it to find and exploit flaws faster; defenders use it to triage and respond.
  • Regional rules multiply. More markets follow China's lead with their own mandatory standards, so global programs need evidence that satisfies many regimes at once.

For our fuller take, see what's next for automotive cybersecurity. [Specific market-size or attack-volume figures should be sourced and marked verify before publishing.]

How do you prepare for an automotive cybersecurity standards audit?

Preparing for an automotive cybersecurity audit means gathering evidence early: CSMS documentation, TARA results, test reports, supplier records, and a software bill of materials.

The mistake teams make is treating the audit as a documentation exercise at the end. The evidence has to describe what actually shipped, and that's hard to reconstruct after the fact. A workable timeline looks roughly like this, though it varies by program scope:

  1. Roughly 9 to 12 months out: confirm which standards apply, stand up or refresh your CSMS, and assign responsibilities across suppliers.
  2. 6 months out: complete TARA for each vehicle type, define cybersecurity requirements, and start collecting supplier evidence.
  3. 3 months out: run verification and tests, generate an SBOM for the shipping build, and close gaps the evidence reveals.
  4. Audit window: present documentation, test reports, and traceability that link your design decisions to what's actually in the vehicle.

A ground-truth software inventory of the firmware is what keeps step four honest, because it shows the real contents of the build rather than what the design docs claim.

What's on a UN R155 audit checklist?

A UN R155 audit checklist covers CSMS processes, risk management, monitoring and incident response, supply-chain controls, and per-vehicle type approval evidence including TARA.

The regulation splits into two approvals: a CSMS approval for your organization's processes, and a vehicle type approval for the specific product. You need both, and the second depends on the first. Here's a practical checklist.

AreaWhat an assessor checksEvidence to prepare
CSMS in placeDocumented cyber risk processes across the lifecycleCSMS policy and process records
Risk managementTARA performed, risks treated with proportionate mitigationsTARA, risk register, Annex 5 mitigations
Monitoring and responseAbility to detect and respond after productionIncident response plan, monitoring and threat reports
Supply chainTier 1 and Tier 2 risks identified and managedSupplier agreements, component inventory, SBOM
Vehicle type approvalCSMS applied to the specific type; controls verifiedTest reports, verification and traceability evidence
Software updatesSafe and secure update process (UN R156)SUMS documentation, update integrity records

How does Finite State help meet automotive cybersecurity standards?

Finite State analyzes the firmware you actually ship, generates SBOMs, prioritizes vulnerabilities, and produces audit-ready evidence mapped to UN R155, ISO 21434, and GB 44495.

Here's the thread running through every standard on this page: they all ask you to prove your security, and the proof has to match what's really in the vehicle. Design documents and source repositories describe intent. The binary inside the electronic control unit is what an attacker actually faces. Finite State works from that shipped reality:

  • We build a ground-truth inventory of firmware, binaries, and supplier SBOMs, including the components nobody documented.
  • We use reachability and exploit context to focus your team on the vulnerabilities that represent real exposure, which is exactly what TARA asks for.

The payoff is leverage: one evidence base, grounded in what you ship, that supports many standards at once instead of a separate scramble for each. The goal isn't a binder that looks compliant. It's a product you can prove is secure, in any market.

Not sure what's inside your firmware before an audit? Check out our Automotive Security Solutions and we'll analyze one of your real builds against the standards that apply to you.

Doc McConnell

Doc McConnell

Head of Policy and Compliance

Doc McConnell is a public policy and cybersecurity leader with over a decade of experience shaping national technology policy within the U.S. government. Prior to joining Finite State, he led strategic policy development for federal cybersecurity at the Cybersecurity and Infrastructure Security Agency and served as a policy advisor within the White House Office of Management and Budget.

Doc holds a Master of Information and Cybersecurity from the University of California, Berkeley, and a Master of Public Policy from the University of Virginia. He is a Certified Information Systems Security Professional (CISSP).

Ready to Level Up Your Security Knowledge?

Join thousands of security professionals learning from the best in the industry

Start Learning TodayStart Learning Today
Finite StateFinite State

Finite State is the Product Security Automation Platform that functions as an autonomous Product Security OS: design → verify → prove, grounded in what you ship.

Platform

Platform Overview
Ground Truth Inventory
Exploitability-Based Prioritization
Design-Time Architecture Security
Automated Evidence-Backed Compliance

Solutions

Device Manufacturers
Automotive
Medical Devices
Energy & Utilities
Government
Industrial

Resources

Blog
Resource Library
Webinars & Videos
Events
Documentation

Company

About Us
CareersHIRING
Press & News
Contact Sales
Media Inquiries
X

© 2026 Finite State. All rights reserved.

Privacy PolicyTerms of UseCustomer Terms and Conditions
Finite StateFinite State
Finite StateFinite State
Get a DemoGet a Demo