TL;DR: Connected vehicle compliance is shifting from engineering quality to supply chain provenance, according to Finite State, as the US Connected Vehicle Rule bans China- and Russia-linked software in model year 2027 and hardware in model year 2030. Provenance visibility, not just cybersecurity assurance, is now the gating control for vehicle software and hardware.
At a glance
What this is: This is an analysis of the US Connected Vehicle Rule and its core finding: automakers must prove the origin of connected vehicle software and hardware, not just secure it.
Why it matters: It matters because provenance and supplier traceability are now compliance controls, and the same visibility gap that weakens automotive supply chains also weakens broader identity and third-party governance.
By the numbers:
- Software restrictions take effect with model year 2027, while hardware restrictions take effect with model year 2030.
Context
The Connected Vehicle Rule turns component provenance into a national security and compliance issue. For connected cars, the question is no longer only whether a system is secure in operation, but whether every software and hardware dependency can be traced to an acceptable source before it ships.
That distinction matters to IAM and supply chain governance because the control problem is identity-like at the supplier layer: who made the component, who controls it, and whether that trust chain can be evidenced. In practice, this is a lifecycle and assurance problem, not a single-point technical control, and vehicle programmes that lack component-level visibility will struggle to certify compliance.
For identity and security teams supporting embedded or connected products, the article is a reminder that provenance controls are becoming a governance requirement, not an audit luxury. The starting position in many programmes is still weaker than the rule assumes.
Key questions
Q: What breaks when connected vehicle provenance cannot be proven?
A: When provenance cannot be proven, manufacturers lose the ability to certify that connected vehicle software or hardware is free of prohibited foreign-linked components. That creates a compliance failure, but it also creates a governance failure: the organisation cannot reliably separate acceptable suppliers from disallowed ones once integration is complete.
Q: Why does the Connected Vehicle Rule matter beyond automotive compliance?
A: It shows that supply chain origin can become a security control in its own right. Any environment that depends on third-party components, firmware, or embedded software should expect provenance evidence to become part of the assurance model, especially where national security or regulated market access is involved.
Q: Where do provenance controls fail in practice for complex products?
A: They fail when teams rely on supplier attestations, spreadsheets, or source-only reviews instead of artefact-level inspection. In complex products, prohibited dependencies often enter through nested suppliers or compiled firmware, so the failure is usually hidden until the organisation examines what actually ships.
Q: What should organisations do when software and hardware deadlines differ?
A: They should manage software and hardware provenance in one programme, because the later hardware deadline will still force earlier sourcing decisions. Sequencing matters, and disconnected compliance tracks often create redesign pressure too late in the product lifecycle.
Technical breakdown
Why provenance, not security testing, is the compliance core
The rule is built around supply chain origin, not vulnerability status. A component can pass security testing and still be prohibited if it is linked to China or Russia. That makes provenance a distinct control plane from secure development or product assurance. For connected vehicles, the evidence must show where software and hardware came from, how they were integrated, and whether any restricted entity sits in the chain. In identity terms, this is closer to trust establishment than runtime defence: the question is whether the component is allowed to exist in the system at all.
Practical implication: Build provenance evidence into procurement and product approval, not into post-build security review.
Why automated driving systems increase traceability pressure
Automated Driving System software is especially hard to govern because it is assembled from many suppliers and nested dependencies. A single prohibited dependency buried deep in the stack can make the entire vehicle non-compliant, even if the top-level application appears clean. That means SBOM-style visibility alone may be insufficient unless it reaches the shipped binary and the supplier chain behind it. The article’s binary-level emphasis is important: source code reviews and spreadsheets do not reliably reveal what actually ships.
Practical implication: Trace ADS dependencies to the binary and firmware level before model-year lock, not after integration.
How the rule treats connectivity hardware differently from software
Vehicle Connectivity System hardware and software are both in scope, but the timing differs. Software has a legacy cutoff, while hardware has a harder prohibition horizon and no equivalent legacy exemption. That creates a sequencing challenge for manufacturers, because software choices often constrain hardware sourcing long before production. The governance lesson is that software and hardware provenance cannot be managed as separate workstreams. They are coupled, and the stricter hardware position will often force earlier redesign decisions than teams expect.
Practical implication: Align software and hardware supplier reviews in one provenance programme so sourcing changes happen before the hardware deadline.
Threat narrative
Attacker objective: The underlying risk is that a foreign-linked supplier could create data exposure or remote interference paths inside a connected vehicle fleet.
- Entry occurs when a connected vehicle integrates software or hardware from a restricted foreign-linked supplier into the connectivity or driving stack.
- Credential or trust abuse is not the main issue here; the attack surface is the supply chain trust relationship itself, which the rule treats as an unacceptable national security exposure.
- Impact is regulatory and operational: the vehicle may be barred from sale or import, and the manufacturer may lack defensible evidence to certify conformity.
Breaches seen in the wild
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Provenance control is becoming a security discipline of its own: the Connected Vehicle Rule shows that proving origin can matter as much as proving resilience. Security teams have long treated supplier assurance as a governance layer, but this rule makes supply chain origin a hard compliance boundary. For practitioners, that means traceability evidence must be operationalised, not collected reactively.
Connected vehicle programmes now need component-level trust mapping: the rule does not care whether a telematics unit functions correctly if its origin is prohibited. That creates a governance model closer to identity assurance than classic product security, because the critical question is whether the component is authorised to participate at all. Practitioners should treat supplier lineage as a first-class control.
Binary-level visibility is the named concept that changes the game: spreadsheets and vendor attestations are not enough when the shipped artefact is what regulators judge. The article’s emphasis on what actually ships exposes a familiar failure mode in complex supply chains, where hidden dependencies survive until an audit or enforcement event. The practitioner conclusion is clear: provenance evidence must be derived from the artefact itself.
The rule accelerates a broader shift from cybersecurity to supply chain accountability: automotive standards such as UN R155 and ISO 21434 still matter, but they answer a different question. Connected vehicle governance now has to satisfy both secure engineering and origin-based restriction checks. For teams, that means compliance design must include procurement, legal, engineering, and product assurance from the start.
From our research library:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Binary-level provenance is now the practical control boundary: connected vehicle teams cannot assume that vendor declarations or source repositories reflect the shipped artefact. That means evidence collection has to move closer to build outputs, firmware images, and supplier lineage if organisations want to avoid late-stage compliance failures.
The same governance pressure is appearing across third-party software more broadly, which is why supply chain assurance now sits alongside IAM and NHI governance in mature programmes. According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security. That pattern reinforces the need to govern who and what is trusted across the product lifecycle.
For practitioners
- Map every connected component to its supplier lineage Create a current inventory of vehicle connectivity and ADS components, then trace each one to its legal and ownership origin. Focus on embedded software, firmware, and connectivity modules that can enter the product through layered suppliers.
- Move provenance checks into release gating Require provenance evidence before model-year freeze so restricted sources are removed before integration, not after build completion. Treat release approval as dependent on component origin evidence, not just security test results.
- Align procurement, engineering, and legal review Use one approval path for supplier onboarding, prohibited-entity screening, and technical integration so decisions are not split across disconnected teams. The rule’s compliance burden sits across commercial and technical ownership.
- Validate shipped binaries, not just source declarations Inspect firmware and compiled artefacts to confirm what is actually embedded in the vehicle. Source attestations alone will miss inherited dependencies and repackaged components.
Key takeaways
- The Connected Vehicle Rule treats provenance as a compliance control, not a documentation exercise.
- The rule’s deadlines separate software and hardware, which forces earlier supplier decisions than many programmes expect.
- Teams that cannot prove what actually ships will struggle to defend connected vehicle certification or market access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CSA Cloud Controls Matrix, NIST CSF 2.0, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Supplier provenance and controlled component origin are core trust issues in this rule. |
| Recommendation — Map supplier trust and origin evidence to IAM-style governance so prohibited sources are excluded before integration. | ||
| NIST CSF 2.0 | ID.SC-01 — Supply Chain Risk Management Processes | The rule depends on disciplined supply chain risk processes across vehicle components and suppliers. |
| Recommendation — Document supply chain risk processes for component provenance and keep them current across engineering and procurement. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s governance challenge is who can introduce and approve third-party components into the product chain. |
| Recommendation — Restrict approval paths for third-party component onboarding and revoke access to untrusted supplier sources. | ||
| SLSA | L3 — Provenance and Build Integrity | Binary-level shipping evidence and build provenance are central to proving what actually ships. |
| Recommendation — Adopt build provenance controls so shipped firmware and binaries can be traced back to trusted sources. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party supplied components create trust and lifecycle risk similar to vulnerable external NHIs. |
| Recommendation — Review third-party component trust paths and remove any supplier dependencies that cannot be validated end to end. | ||
Key terms
- Connected Vehicle Rule: 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.
- Vehicle Connectivity System: A Vehicle Connectivity System is the set of modules that lets a vehicle communicate outside itself. In this article, it includes telematics control units and wireless interfaces such as Bluetooth, cellular, satellite, and Wi-Fi. These components expand functionality but also enlarge the cybersecurity and supply chain exposure surface.
- Highly Automated Driving System: A highly automated driving system is a vehicle control system that can perform some or all driving tasks with limited or no human input, depending on the level of automation. In practice, the legal treatment depends on how much control the system has and whether a human operator remains responsible.
- Certificate Of Conformity: A Certificate of Conformity is a regulated vehicle document that states the vehicle meets required homologation standards. In digital form, it becomes a verifiable compliance artefact whose usefulness depends on the authenticity of the issuer and the integrity of the content.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the control thinking needed for supplier trust, lifecycle evidence, and access governance.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org