US Connected Vehicle Rule: Live Since March 2025. MY2027/MY2030 Supply-Chain Playbook

The U.S. connected vehicle rule changes an assumption that has shaped automotive cybersecurity for years: a product can be technically secure and still be unacceptable for the market because of who designed, supplied, controlled, or can influence critical technology.

The final rule issued by the U.S. Department of Commerce Bureau of Industry and Security, or BIS, restricts certain Vehicle Connectivity System hardware and connected software associated with China or Russia. The software prohibitions begin with Model Year 2027. The VCS hardware restrictions begin with Model Year 2030, or 1 January 2029 for covered hardware without a model year. The rule took effect on 17 March 2025 and introduces annual declarations of conformity for covered manufacturers and importers, subject to limited exemptions and authorization processes.

This is not a normal component-compliance exercise. The evidence must connect corporate ownership, development control, software provenance, hardware supply chains, vehicle configurations, and model-year applicability. A static supplier list will not be enough.

This guide explains how OEMs and suppliers can build a repeatable compliance operating model without creating another disconnected spreadsheet program.

What the rule is trying to control

The rule addresses national-security risks arising from connected-vehicle technologies that may provide persistent access to vehicles, sensitive data, critical infrastructure, or automated-driving functions. It focuses on two broad technology areas:

• Vehicle Connectivity Systems: hardware and software that enable vehicles to communicate through cellular, satellite, Wi-Fi, Bluetooth, radio-frequency, or similar external connections.
• Automated Driving Systems software: software that collectively enables a highly automated vehicle to operate without a human driver performing the driving task in the defined context.

The legal definitions, exclusions, thresholds, and covered transactions matter. Organizations should classify products against the final rule and BIS guidance rather than relying on informal labels such as "telematics" or "autonomy."

The operational implication is broader than country of manufacture. Teams must understand ownership, control, jurisdiction, and direction. A module assembled in one country may contain software developed, maintained, or remotely administered by an entity subject to another jurisdiction. A U.S. subsidiary may still require deeper analysis of its parent, governance, personnel access, and update authority.

The compliance timeline

The most important dates are:

• 17 March 2025: the rule became effective.
• Model Year 2027: prohibitions apply to covered VCS software and ADS software, and to sales of certain connected vehicles by manufacturers owned by, controlled by, or subject to the jurisdiction or direction of China or Russia.
• Model Year 2030: prohibitions apply to covered VCS hardware imports.
• 1 January 2029: the hardware prohibition applies to covered hardware that is not associated with a model year.

The software date is the immediate priority because Model Year 2027 sourcing and platform decisions may already be locked or close to lock. Software is also harder to inventory than hardware. It can be embedded in supplier binaries, updated after start of production, delivered through cloud-managed services, or maintained by teams outside traditional purchasing channels.

A compliant launch decision therefore needs evidence earlier than the vehicle import or sale date. Procurement, architecture, software release, and supplier-approval gates must incorporate the rule now.

Why normal bills of material are insufficient

A mechanical bill of material answers what part was purchased. A software bill of materials answers which software components are included. The BIS rule requires a third view: who designed, developed, manufactured, supplied, owns, controls, directs, updates, or can materially influence the covered technology.

A useful compliance model links:

Vehicle model year -> vehicle platform -> ECU or system -> VCS/ADS function -> hardware component -> software package or binary -> supplier -> development entity -> parent and controlling entities -> country and jurisdiction indicators -> transaction and declaration evidence.

No single traditional artifact contains all of this. Procurement systems hold supplier names and part numbers. Architecture tools hold functions and interfaces. SBOM systems hold packages. Legal teams hold ownership analyses. Release systems hold deployed versions. Trade-compliance teams hold declarations.

The challenge is to create a controlled evidence graph across these sources without turning every update into a manual investigation.

Start with product and transaction classification

The first workstream is not supplier outreach. It is determining what is in scope.

For each U.S.-bound vehicle program, document:

1. Whether the vehicle meets the rule’s connected-vehicle definition and applicable weight or product criteria.

1. Which systems perform VCS functions.

1. Which software contributes to covered VCS functionality.

1. Whether any ADS software falls within scope.

1. Which hardware components are covered VCS hardware.

1. Whether the organization is acting as a connected-vehicle manufacturer, VCS hardware importer, or another covered party.

1. Which model-year date applies.

1. Whether an exemption, general authorization, or specific authorization may be relevant.

Classification should be versioned. A system that is out of scope in one architecture may become covered after adding remote connectivity, a new wireless chipset, or an automated-driving feature. A product change should therefore trigger classification review.

Do not classify by department. The same domain controller may contain connectivity, infotainment, diagnostics, and driver-assistance software. Scope follows function and technology, not the organizational chart.

Build a covered technology inventory

A reliable inventory needs four layers.

Functional layer

Identify the vehicle functions that connect externally or contribute to ADS. Include direct and indirect connectivity, remote commands, diagnostics, fleet services, app integration, software updates, data upload, and service-to-service communication.

Architecture layer

Map the ECUs, high-performance computers, gateways, modems, wireless chipsets, antennas, network interfaces, operating systems, middleware, and cloud dependencies that implement those functions.

Software and hardware layer

Record software identifiers, versions, suppliers, build origin, source or binary status, update authority, hardware part numbers, manufacturing source, and subcomponents. The inventory should distinguish an open-source library from the entity that integrates and controls the covered software product.

Control and ownership layer

Record the relevant supplier legal entity, parent entities, beneficial or controlling ownership where required, development locations, administrative access, maintenance teams, remote-support arrangements, and contractual update rights.

This inventory becomes the basis for due diligence, declarations, change control, and audit response.

Supplier due diligence that goes beyond a questionnaire

A questionnaire is useful only when answers can be verified and refreshed. Generic questions such as "Do you comply with U.S. law?" provide little evidence.

Ask suppliers for structured information covering:

• Exact legal entity providing the product or service.
• Parent, controlling, and relevant affiliated entities.
• Locations of design, development, integration, manufacturing, testing, hosting, support, and maintenance.
• Identities and roles of sub-suppliers contributing covered hardware or software.
• Source-code ownership and who can approve code changes.
• Who holds signing keys, repository administration, build-system access, and update authority.
• Remote access paths and support personnel.
• Software and hardware provenance records.
• Notification obligations for ownership, personnel, location, or sub-supplier changes.
• Attestations supported by documents, not only a signature.

Risk-based verification may include corporate-registry checks, contract review, build and signing evidence, software-repository access review, site information, SBOM analysis, hardware teardown, or independent testing.

The supplier should also identify uncertainty. An honest unknown can be investigated. An unsupported absolute statement creates hidden risk.

Define evidence for the annual declaration of conformity

BIS guidance states that covered connected-vehicle manufacturers and VCS hardware importers generally must file annual declarations of conformity before covered import or sale activities, subject to limited exemptions.

A declaration process should have a repeatable evidence pack behind it. That pack may include:

• Covered vehicle and hardware scope.
• Model years and configurations.
• Classified VCS and ADS functions.
• Supplier and sub-supplier list.
• Software and hardware provenance.
• Ownership and control analyses.
• Due-diligence results and unresolved exceptions.
• Approved authorizations or advisory opinions.
• Change history since the previous declaration.
• Responsible executives and reviewers.
• Record-retention location and access controls.

The declaration should not be treated as a legal form completed at year end. It is the output of ongoing product and supply-chain governance. If the underlying inventory is updated continuously, the annual filing becomes a controlled review. If not, it becomes a high-pressure reconstruction exercise.

Manage software differently from traditional parts

Software creates several compliance traps.

Embedded supplier binaries

A Tier-1 may deliver a binary containing connectivity software from multiple sub-suppliers. The OEM needs enough provenance to determine who developed and controls the covered functions, even when source code is unavailable.

Cloud-controlled vehicle functions

Some connected functionality depends on backend software, credentials, policy engines, or remote configuration. Teams should assess whether control over the vehicle-facing software or service creates covered exposure, rather than limiting review to code stored in the vehicle.

Post-production updates

A vehicle may be compliant at sale and later receive a software update that changes the supplier, component, administrative path, or functionality. Release governance must block an update that invalidates the compliance basis.

Shared platforms

One software platform may be used across U.S. and non-U.S. vehicles. The organization needs variant-aware configuration and deployment evidence so a prohibited component does not enter the U.S. build through reuse or emergency patching.

Development tools and outsourced engineering

Not every tool used to build software is covered technology, but outsourced development, code control, signing authority, and remote administration can affect the ownership-and-control analysis. Legal and technical teams should review the actual operating model.

Establish change triggers

The compliance conclusion can change without a new vehicle platform. Define events that automatically reopen the assessment:

• New software supplier or sub-supplier.
• Change in corporate ownership or control.
• Acquisition, merger, joint venture, or restructuring.
• New development or support location.
• Transfer of source-code, repository, signing, or update authority.
• New wireless interface or connectivity feature.
• ADS feature expansion.
• Hardware redesign or substitute component.
• Emergency vulnerability patch from a new source.
• Backend migration or managed-service change.
• Material change in model-year configuration.

Each trigger needs an owner, review deadline, required evidence, and release consequence. A change that affects the declaration should not depend on someone remembering to email trade compliance.

Integrate the rule into sourcing and contracts

Contracts should make the required visibility and response possible. Consider clauses for:

• Complete and accurate ownership and control information.
• Disclosure of covered sub-suppliers.
• Prior notification and approval of material changes.
• Software and hardware provenance delivery.
• Audit and verification rights.
• Access to supporting records for the required retention period.
• Immediate notification of inaccurate prior statements.
• Restrictions on unauthorized remote access and update authority.
• Cooperation with BIS inquiries, authorizations, or remediation.
• Transition assistance if a supplier becomes prohibited.
• Liability and cost allocation for non-compliant changes.

Commercial teams also need an exit strategy. If a critical supplier becomes ineligible, can the organization replace the component, rehost the software, transfer maintenance, or isolate the function before the applicable model year?

Use authorizations and advisory opinions deliberately

The BIS framework includes general authorizations, specific authorizations, and advisory opinions. These mechanisms should not be viewed as shortcuts around due diligence. They require a well-defined fact pattern.

Before seeking one, assemble:

• The exact transaction and product configuration.
• Relevant entities and ownership relationships.
• Technology scope and function.
• Access, control, update, and data flows.
• Security mitigations and governance.
• Alternatives considered.
• Time sensitivity and business impact.
• Monitoring commitments if approval is granted.

An advisory opinion is most useful when the technical architecture and corporate facts are stable enough to describe precisely. Vague requests create vague value.

Design a cross-functional governance model

No single function can own this rule end to end.

• Trade compliance and legal interpret the rule, entities, authorizations, and filing obligations.
• Cybersecurity and architecture identify VCS/ADS functions, trust boundaries, access paths, and technical control.
• Procurement and supplier quality obtain and verify supplier information.
• Software engineering and DevSecOps maintain build, repository, signing, and release provenance.
• Hardware engineering and manufacturing manage component origin and substitutions.
• Connected services and cloud teams document backend control and remote administration.
• Program management enforces model-year gates.
• Executive management approves declarations and risk decisions.

Create one decision forum with defined escalation criteria. Conflicting answers should be resolved before sourcing or release approval, not before the annual filing deadline.

A practical compliance workflow

Step 1: Screen the portfolio

Identify U.S.-bound programs, covered vehicle types, model years, VCS hardware, connected software, and ADS software.

Step 2: Map entities to technology

Link each covered item to the supplying, developing, controlling, supporting, and updating entities.

Step 3: Collect and verify evidence

Use structured supplier submissions, internal records, legal analysis, SBOMs, architecture data, and access-control evidence.

Step 4: Resolve exceptions

Replace, redesign, seek authorization, or document why the item is outside scope. Track assumptions and expiry dates.

Step 5: Gate releases and sourcing

Require a current compliance status before purchase approval, software release, hardware substitution, or U.S. deployment.

Step 6: Prepare the declaration

Generate the annual filing scope and evidence summary from the controlled inventory.

Step 7: Monitor change

Run continuous change detection across suppliers, corporate ownership, software, hardware, access, and vehicle configurations.

Metrics for management

Useful indicators include:

• Percentage of U.S.-bound covered systems fully classified.
• Percentage of covered software with verified development and control provenance.
• Percentage of covered hardware with complete sub-tier traceability.
• Number of unresolved entity-ownership questions.
• Number of supplier changes awaiting reassessment.
• Average time to assess a software or hardware substitution.
• Percentage of Model Year 2027 releases protected by a compliance gate.
• Declaration evidence completeness by program.
• Number and age of authorization-dependent configurations.
• Time required to answer which U.S. vehicles use technology from a named entity.

These metrics should be drillable to vehicle, version, supplier, and evidence. Aggregates alone cannot support a declaration.

How a connected CSMS evidence layer supports the rule

The rule is not an ISO/SAE 21434 requirement, but the same connected product model can reduce duplication. Architecture, suppliers, SBOMs, vulnerabilities, software versions, controls, approvals, and deployed configurations already matter to cybersecurity management. Adding ownership, jurisdiction, control, and declaration attributes creates a U.S. compliance view without building another isolated database.

ThreatZ can serve as the traceability layer between the vehicle architecture, covered technologies, suppliers, software components, evidence, and release decisions. The strongest pilot is one Model Year 2027 program with one high-risk connectivity domain. The output should be a repeatable answer to a simple question: "Which entity controls every covered software element in this configuration, and what proves it?"

Frequently asked questions

Is this only a procurement issue?

No. Procurement holds important supplier data, but software architecture, repository control, signing authority, remote access, update governance, and corporate ownership all affect the analysis.

Does an SBOM prove compliance?

No. An SBOM helps identify software components, but it does not by itself establish ownership, jurisdiction, direction, development control, remote administration, or the transaction-level facts required by the rule.

Can a compliant vehicle become non-compliant after sale?

A post-production update or supplier-control change can invalidate the facts supporting the original analysis. Organizations need release and change controls that preserve the compliance basis over time.

What should be completed first for Model Year 2027?

Prioritize covered software classification, supplier and sub-supplier provenance, corporate-control analysis, update authority, and release gating for U.S.-bound configurations.

Should every organization seek an authorization?

No. Authorizations and advisory opinions are fact-specific tools. First determine scope, alternatives, and the exact technical and corporate facts with qualified legal counsel.

Related reading on VxLabs

• CSMS operating model
• ThreatZ integrations
• supplier cybersecurity questionnaire
• Tier-1 to OEM evidence handover

Authoritative references

• BIS Connected Vehicles overview
• BIS Small Entity Compliance Guide for the Connected Vehicles Rule
• BIS Office of Information and Communications Technology and Services