Connected VehiclesCompliance & Regulations

Understanding the Connected Vehicle Rule: What It Requires and How to Comply

Learn what the Connected Vehicle Rule means for automakers, key compliance deadlines, and how Finite State helps companies navigate the new regulation.

Mike Hatherall

Mike Hatherall

February 2, 2026
TL;DR: The Connected Vehicle Rule is a US Commerce Department regulation that bans China- and Russia-linked software and hardware from connected cars sold or imported into the United States. Software restrictions bite starting with model year 2027, hardware with model year 2030. Compliance rests on one thing: knowing exactly where every connected component in your vehicle came from. You can't prove provenance you can't see.

The global automotive industry is facing one of the largest supply chain interventions in its history. The US Connected Vehicle Rule treats the software and hardware inside a connected car as a national security matter, not just an engineering one. For automakers and suppliers, that changes the job. It's no longer enough to know a component works. You have to prove where it, and every piece of software inside it, came from.

This guide covers what the rule is, what it prohibits, when the deadlines land, and how it differs from the automotive cybersecurity standards you already follow. One idea runs through all of it: the rule is a provenance problem, and provenance lives in what actually ships, down to the binary level.

What is the Connected Vehicle Rule?

The Connected Vehicle Rule is a US Commerce Department final rule that prohibits importing or selling connected passenger vehicles containing certain software or hardware linked to China or Russia.

It was issued by the Commerce Department's Bureau of Industry and Security (BIS) on January 16, 2025, and took effect on March 17, 2025. The rule grew out of Executive Order 13873 on securing the information and communications technology supply chain, and it reflects a view that foreign-sourced digital infrastructure in a vehicle can pose an unacceptable risk even in a consumer car. You can read the official BIS final rule in the Federal Register. For the wider regulatory backdrop, our primer on automotive cybersecurity standards sets the scene.

What does the Connected Vehicle Rule prohibit?

The rule prohibits China- and Russia-linked hardware in Vehicle Connectivity Systems and China- and Russia-linked software in either Vehicle Connectivity Systems or Automated Driving Systems, in connected passenger vehicles.

It targets two systems. A Vehicle Connectivity System (VCS) is the hardware and software that handles the car's external wireless communication, things like cellular modems, Wi-Fi and Bluetooth modules, and telematics units that can communicate above 450 MHz. An Automated Driving System (ADS) is software that can perform the full driving task without a human. "Linked to China or Russia" is defined broadly: it covers companies headquartered or incorporated there, entities owned or controlled by those governments or by their nationals, and companies majority-financed by them. The ban applies whether the component is imported on its own or built into a finished vehicle.

Which vehicles and components are actually covered?

The rule covers passenger vehicles under 10,001 pounds. It explicitly excludes low-risk sensing hardware such as LiDAR, radar, cameras, GNSS, and AM/FM radio, which are not treated as Vehicle Connectivity Systems.

This scoping matters, because it tells you where to focus. Commercial vehicles above the weight threshold are not covered by this rule, though BIS has signaled a separate rulemaking may follow. And the sensing stack that many teams assume would be in scope is carved out. What's left in scope is the connectivity and automated-driving software and hardware, which is exactly the part of the vehicle that talks to the outside world. If you're mapping exposure across a broader product line, our work on connected device security challenges covers the same provenance problem outside automotive.

What are the Connected Vehicle Rule compliance deadlines?

Software restrictions take effect with model year 2027. Hardware restrictions take effect with model year 2030, or January 1, 2029 for hardware not tied to a model year. Legacy software before March 17, 2026 is excluded.

Given how long vehicle development and supply chain changes take, these dates are closer than they look. The two-phase structure is deliberate: it gives manufacturers time before the more demanding hardware rules land. But software is often built around specific hardware, so decisions you make to meet the 2027 software deadline can force hardware sourcing changes well ahead of 2030.

MilestoneDate / model yearWhat changes
Rule issuedJanuary 16, 2025BIS publishes the final rule
Rule effectiveMarch 17, 2025Compliance obligations and recordkeeping begin
Legacy software cutoffMarch 17, 2026Covered software created before this date is excluded
Software prohibitionsModel year 2027China/Russia-linked VCS and ADS software banned
Hardware (no model year)January 1, 2029China/Russia-linked VCS hardware banned
Hardware prohibitionsModel year 2030China/Russia-linked VCS hardware banned in vehicles

Note there is no legacy exemption for hardware, unlike software. VCS hardware imported only for warranty or repair of a pre-2030 vehicle is exempted, but that's a narrow carve-out.

What must manufacturers and suppliers do to comply?

Covered manufacturers and importers must run supply chain due diligence, submit an annual Declaration of Conformity certifying they've avoided prohibited transactions, and keep records to back it up.

The Declaration of Conformity is the heart of the compliance mechanism. It's filed at least annually, generally due ahead of the first import or sale of each model year, and it certifies that no prohibited China- or Russia-linked components are present. Behind that certification sits the real work: mapping every supplier across the vehicle lifecycle, identifying dependencies on restricted sources, and reconfiguring supplier networks where needed. Where clean substitution isn't immediately possible, BIS offers two escape valves. General authorizations cover lower-risk categories that BIS publishes on its website and in the Federal Register. Specific authorizations are case-by-case waivers you apply for, reviewed on their own facts. Both demand documentation, and BIS has been sparing in granting individual exemptions.

How is the Connected Vehicle Rule different from existing automotive cybersecurity standards?

Existing standards like UN R155 and ISO 21434 ask whether a vehicle is secure. The Connected Vehicle Rule asks a different question: where did the software and hardware come from, and is that source a national security risk?

This is the distinction that trips teams up. You can have a vehicle that fully satisfies ISO 21434 and where Finite State helps with the engineering, yet still violates the Connected Vehicle Rule because a telematics module traces back to a prohibited supplier. Cybersecurity standards are about the quality of your security engineering. The Connected Vehicle Rule is about provenance and supply chain origin. They're complementary, not interchangeable, and you now have to satisfy both.

Automotive cybersecurity standards (UN R155, ISO 21434)Connected Vehicle Rule
Core questionIs the vehicle engineered securely?Where did the components come from?
FocusThreat modeling, secure development, risk managementSupplier provenance and foreign-adversary links
Issued byUN / ISOUS Commerce Department (BIS)
How you prove itSecurity process evidenceSupply chain mapping and Declarations of Conformity

For a fuller comparison of the frameworks in play, see our overview of automotive standards and regulations and our look at the UN R155 regulation for connected vehicles.

What are the national security risks behind the rule?

The concern is that connected vehicles are data-rich, software-defined platforms. Foreign-linked components could extract sensitive data about drivers or locations, or let an adversary remotely manipulate a vehicle.

BIS framed VCS and ADS technologies as an undue risk to national security when supplied by entities with a sufficient nexus to China or Russia, because malicious access to those supply chains could expose personal data or allow remote interference. That thinking is spreading beyond this one rule. A proposed Connected Vehicle Security Act of 2026 would widen the country list to include Iran and North Korea, and defense legislation has moved to keep adversary-nation connected vehicles off military installations [verify before publishing]. The direction of travel is clear: connected vehicle oversight is becoming a durable part of US national security policy, not a one-off.

How does the Connected Vehicle Rule affect autonomous driving technology?

It puts Automated Driving System software squarely in scope. Any ADS software that can perform the full driving task is banned from covered vehicles if it's designed, developed, or supplied by China- or Russia-linked entities.

Autonomous driving depends on exactly the kind of complex, multi-sourced software stack the rule is built to police. For companies building or integrating ADS, provenance tracking can't be an afterthought bolted on before a submission. It has to be built into how the software is assembled, because an ADS stack pulls in components from many suppliers, and a single prohibited dependency buried deep in that stack can put the whole vehicle offside.

How does Finite State support Connected Vehicle Rule compliance?

Finite State helps automakers and suppliers see what's actually inside their software and hardware, down to the binary level, so they can map provenance, find prohibited components, and build defensible compliance evidence.

The rule is, at its core, a visibility problem. You cannot certify a supply chain you cannot see, and the risky component is often something no one on the team consciously chose. It arrived through a supplier, a reference design, or a firmware image with no source attached. Our binary analysis decomposes shipped firmware and binaries into their real components, revealing origin and dependencies that a source-only or spreadsheet-based review would miss. From there, we help teams map hardware and software suppliers across the vehicle lifecycle, identify dependencies on restricted sources, assess whether a specific authorization is worth pursuing and build the strongest application, and formalize the internal procedures and documentation that BIS expects from manufacturers and that manufacturers now expect from their suppliers.

We work alongside automakers, Tier-1 suppliers, and their legal advisers, combining technical, legal, and policy insight into how the rule is written and how it's likely to be enforced. Compliance shouldn't be a last-mile scramble before a model year locks. It should be a continuous, evidence-backed workflow grounded in what you actually ship.

If your business touches automotive electronics, embedded systems, or vehicle software, now is the time to act. See how we support connected vehicle manufacturers, review our automotive compliance and security management datasheet, or book a call with our services team to start mapping your exposure.

Tags

#regulation
Mike Hatherall

Mike Hatherall

Mike Hatherall is Lead Solutions Architect for EMEA at Finite State and a seasoned cybersecurity and network engineering professional. He brings deep expertise in asset management, vulnerability response, and OT security, with hands-on experience in platforms like Forescout, Armis, and ServiceNow. Mike previously ran his own MSP for 12 years, successfully growing and selling the business.

Related Articles

Understanding The EU CRA's SBOM & Technical Documentation Requirements

Understanding The EU CRA's SBOM & Technical Documentation Requirements

Ensure compliance with the EU Cyber Resilience Act. Learn how IoT manufacturers can streamline SBOM creation, updates, and documentation with expert t...

May 21, 2026
Router being scanned

The FCC's Waiver Extension for Routers Is the Right Call for Cybersecurity

Why patch status matters more than where it’s assembled—and what device makers should take from the policy reversal.

May 19, 2026
Conformity Assessments: Understanding the EU Cyber Resilience Act Requirements

Conformity Assessments: Understanding the EU Cyber Resilience Act Requirements

Learn about the EU Cyber Resilience Act's conformity assessments. Discover how IoT manufacturers can ensure compliance based on product risk categorie...

May 12, 2026

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