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
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.
| Milestone | Date / model year | What changes |
|---|---|---|
| Rule issued | January 16, 2025 | BIS publishes the final rule |
| Rule effective | March 17, 2025 | Compliance obligations and recordkeeping begin |
| Legacy software cutoff | March 17, 2026 | Covered software created before this date is excluded |
| Software prohibitions | Model year 2027 | China/Russia-linked VCS and ADS software banned |
| Hardware (no model year) | January 1, 2029 | China/Russia-linked VCS hardware banned |
| Hardware prohibitions | Model year 2030 | China/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 question | Is the vehicle engineered securely? | Where did the components come from? |
| Focus | Threat modeling, secure development, risk management | Supplier provenance and foreign-adversary links |
| Issued by | UN / ISO | US Commerce Department (BIS) |
| How you prove it | Security process evidence | Supply 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.


