A US Commerce Department rule that restricts connected vehicle software and hardware linked to China or Russia. It is a provenance and national security control, not a product security standard, and it requires manufacturers to prove the origin of covered components before sale or import.
What the rule covers and why provenance matters
The connected vehicle Rule is a provenance control, not a product security baseline. Its core purpose is to keep certain connected vehicle software and hardware with China or Russia-linked origins from entering the US market without manufacturer proof about where covered components came from.
That distinction matters because the rule is aimed at supply-chain trust, sourcing transparency and national security assurance. The security question is not whether a device is hardened after deployment, but whether the component supply path itself is acceptable before sale or import.
How it changes the security model for connected vehicles
Connected vehicles combine software-defined functions, communications, remote services and embedded hardware. When provenance is restricted at the component level, manufacturers must treat origin evidence as part of the vehicle’s trust boundary, alongside engineering, testing and compliance artefacts.
In practice, this pushes security and compliance teams to think about bill of materials quality, component traceability and supplier attestations as gating evidence. If a supplier relationship is opaque, the risk is not just technical weakness, but the possibility that a restricted component enters the fleet unnoticed.
For broader supply-chain risk context, the vehicle software and firmware chain is similar to other provenance-sensitive environments where build, sourcing and integrity evidence are as important as the finished system.
What organisations must verify before shipment or import
Organisations need an auditable asset view that maps covered software and hardware to suppliers, subcomponents and country-of-origin evidence. That usually means reconciling engineering records, procurement data and vendor documentation so that the final declaration is defensible rather than assumed.
Vendor advisories and government guidance remain the authoritative source for product scope and enforcement detail, because the rule turns on the exact items covered and the evidence required. Manufacturers should not rely on marketing descriptions or broad supplier assurances when the actual compliance question is component provenance.
Where sourcing chains are long or tiered, the control problem is often completeness rather than secrecy. A missing subcontractor relationship, unverified firmware origin or undocumented integrator can create a compliance gap even when the vehicle itself appears ordinary.
What happens if provenance is wrong or incomplete
If a manufacturer cannot prove origin, the immediate issue is regulatory non-compliance, but the deeper security concern is uncontrolled dependency on foreign-linked components inside safety-critical and connected systems. That can affect market access, remediation cost and confidence in the supplier chain.
Provenance failures also complicate incident response. If a suspect component is discovered after sale, the organisation may have to determine whether the issue is limited to documentation, or whether the component itself also creates a technical exposure that needs containment, replacement or withdrawal.
Because the rule is about origin assurance, a weak evidence trail can be as damaging as a technical defect. In connected vehicle programmes, incomplete provenance often becomes a governance failure first and a security problem second.
Risk and Threat Considerations
The main risk is that a connected vehicle programme accepts a component whose origin is restricted, undocumented or misrepresented. In a regulated supply chain, that can create compliance exposure, delayed launch decisions and expensive rework across manufacturing, procurement and legal review.
Failure mechanism: A manufacturer relies on incomplete supplier attestations or weak component traceability, then ships or imports covered software or hardware without being able to prove origin. That leaves the organisation exposed to enforcement action and to downstream uncertainty about whether the affected component should be trusted, replaced or isolated.
Impact: The result can be blocked sales or imports, forced remediation of already-built inventory, and a broader loss of confidence in the supplier chain used for connected vehicle platforms.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-15 — Service Provider Management | Connected vehicle provenance depends on supplier oversight and third-party assurance. |
| Recommendation — Verify supplier provenance and require documented component-origin evidence before approving covered vehicle parts. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | The rule is fundamentally a supply-chain provenance control for covered hardware and software. |
| Recommendation — Apply SA-12 to maintain trusted sourcing evidence for covered components and imported systems. | ||
| ISO/IEC 27001:2022 | A.5.21 — Managing information security in the ICT supply chain | The subject is a provenance and supplier-chain control over technology components. |
| Recommendation — Use A.5.21 to govern supplier-origin evidence and supply-chain security requirements for connected vehicle components. | ||
Practitioner Guidance
Why practitioners should care: This rule is easiest to fail at the seams between procurement, engineering and compliance. The practical challenge is not only identifying the part, but preserving proof that the entire provenance chain is documented well enough to withstand review.
Governance implication: Ownership should be explicit for component provenance, supplier attestations and exception handling so that no team assumes another has verified the evidence. Where the rule applies, compliance sign-off should be tied to the same source records used to build and ship the product.
Practitioner takeaway: Treat origin evidence as a required release artifact, not a post-hoc compliance exercise.
Related resources from NHI Mgmt Group
- How should automotive manufacturers adapt their connected vehicle sourcing strategy to comply with the new US cyber rule?
- Why does the new rule create operational risk for connected vehicle supply chains?
- What is the difference between software prohibitions and hardware prohibitions in the new connected vehicle rule?
- How should automotive teams govern machine identities across connected vehicle environments?