What is the difference between software prohibitions and hardware prohibitions in the new connected vehicle rule?

Software prohibitions take effect earlier and restrict the use of ADS and VCS software with ties to China or Russia for model year 2027. Hardware prohibitions arrive later, targeting VCS and ADS hardware for model year 2030, or January 1, 2029 for units without a model year. Practitioners should treat them as separate compliance workstreams.

How the rule splits software from hardware compliance

The distinction is about what the rule regulates and when each obligation starts. Software prohibitions apply first and focus on ADS and VCS software ties to China or Russia, while hardware prohibitions arrive later and focus on ADS and VCS physical components. That timing difference matters because it changes procurement, engineering, testing, and supplier review priorities.

For practitioners, the key question is whether the item is a code-dependent function or a physical component subject to the later hardware cutoff. A program that is safe from a software standpoint can still be blocked later at the hardware stage if the underlying component chain is covered by the hardware restriction.

That creates two different compliance lenses. Software review is about what is running and how it is sourced, while hardware review is about what is embedded, manufactured, or installed in the vehicle platform. Teams should not assume a single supplier clearance covers both.

Why the timing and scope are not interchangeable

The staggered dates are a material part of the rule. Software prohibitions begin with model year 2027, or earlier depending on the applicable implementation timeline, while hardware prohibitions are deferred to model year 2030, or January 1, 2029 for units without a model year. The later hardware date gives manufacturers more time, but it also extends the period during which software and hardware compliance can diverge.

That divergence can affect design freezes, supplier contracts, and certification planning. A connected vehicle program may need one set of controls for software sourcing and a different set for hardware bills of materials, especially where the same platform spans several model years. Treating both as one combined gate can leave a gap in evidence or ownership.

It also means that a platform-level “compliant” label is not enough on its own. The rule is easier to misread if teams assume the hardware date simply mirrors the software date. It does not, and that difference can change when a vehicle line can ship.

What practitioners should separate in their control model

Software prohibitions are usually evaluated through release engineering, update pipelines, and product sourcing controls. Hardware prohibitions require supplier attestation, component traceability, and platform-level inventory discipline. The right control model is therefore split by artifact type, not just by business unit.

Engineering, legal, and procurement each have a role, but they need different evidence. Software teams should be able to show what code paths, updates, and vendor dependencies are covered. Hardware teams should be able to show which modules, systems, and installed components are in scope for the later prohibition date.

A useful operational rule is to track software and hardware as separate compliance workstreams with their own owners, deadlines, and sign-off criteria. That avoids false confidence when one stream is complete but the other is still exposed.

Risk and Threat Considerations

Mixed timelines create a real exposure window if organizations assume that software review is enough to clear the whole vehicle platform. The main risk is missed scope, where a system is treated as approved because its software path was reviewed, even though its hardware chain still falls under a later prohibition.

Failure mechanism: Teams collapse two distinct regulatory gates into one internal approval process, so late-stage hardware restrictions are discovered after design, sourcing, or production commitments have already been made.

Impact: That can force redesign, supplier replacement, shipment delay, or costly revalidation, and it can also leave a vehicle program with incomplete compliance evidence for a model year transition.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OC-01 — Organizational Context	Connected vehicle rule compliance depends on knowing scope, ownership, and regulated assets.
	GV.RM-01 — Risk Management Strategy	Different effective dates create distinct regulatory and delivery risks across model years.
Recommendation — Define scope boundaries for software and hardware compliance workstreams. Separate software and hardware risk acceptance by release timeline.
CIS Controls v8	CIS-1 — Inventory and Control of Enterprise Assets	Hardware prohibitions require accurate asset and component inventories across platforms.
Recommendation — Maintain a current inventory of vehicle components and installed systems.
ISO/IEC 27001:2022	A.5.9 — Inventory of information and other associated assets	Tracking software and hardware obligations requires clear asset inventory and ownership.
	A.5.19 — Information security in supplier relationships	The rule’s China or Russia ties make supplier governance central to compliance.
Recommendation — Keep authoritative inventories for software, hardware, and supplier dependencies. Screen supplier relationships for jurisdictional and sourcing exposure.

Practitioner Guidance

What to prioritise: Build a separate compliance register for software and hardware, with distinct dates, evidence requirements, and approval owners. The most common failure is allowing one workstream to “inherit” the other’s sign-off.

What to verify: Confirm that each vehicle platform can prove both software lineage and hardware provenance. If the bill of materials, software release record, and supplier attestations do not line up cleanly, treat the item as unresolved rather than partially cleared.

Practitioner takeaway: The practical difference is not just timing, it is control design, because software and hardware must be proven compliant through different evidence paths even when they belong to the same connected vehicle program.