The 2027 Model-Year Connected Vehicle Rule: What U.S. Auto and Parts Teams Should Check Now

Direct Answer

For 2027 model-year planning, the connected vehicle rule should not be read as a simple ban on vehicles branded or assembled in China. The more useful reading is narrower and more operational: U.S.-bound completed connected vehicles need a documented answer for covered software, vehicle connectivity system hardware, and whether the relevant manufacturer or supplier is owned by, controlled by, or subject to the jurisdiction or direction of the People’s Republic of China or Russia.

The first pressure point is covered software. If a completed connected vehicle imported or sold in the United States includes software that directly enables vehicle connectivity system, or VCS, functions or automated driving system, or ADS, functions at the vehicle level, teams need to know who designed, developed, manufactured, or supplied it.

That is why I would treat the rule as a launch-readiness and evidence problem, not only a legal memo. A procurement file may name the vendor. An engineering file may name the component. The rule pushes teams to connect both records to legal-entity control, software provenance, and conformity evidence.

What Changed

The Bureau of Industry and Security, or BIS, placed connected vehicles inside the information and communications technology and services supply-chain framework. The final rule took effect on March 17, 2025, and restricts certain transactions involving connected vehicles, related hardware, and software with a PRC or Russia nexus.

The rule applies to connected vehicles manufactured for use on public roads that integrate onboard networked hardware with automotive software systems and communicate through DSRC, cellular telecommunications, satellite communication, or other wireless spectrum connectivity. Vehicles used only on rail lines are outside the definition, and connected vehicles over 10,000 pounds gross vehicle weight are also excluded from this definition.

The timing is phased. For 2027 model-year completed connected vehicles, covered software is the near-term operational issue. For VCS hardware, the later milestones are the 2030 model year or, for hardware not associated with a vehicle model year, January 1, 2029.

The practical mistake is to manage this as one vehicle-level question. A single vehicle program may have a 2027 covered-software issue, a later VCS hardware issue, and a separate manufacturer-control question.

The Boundary Questions

Area	Question to answer	Evidence to organize
Vehicle scope	Is this a public-road connected vehicle within the rule, and is it not over the 10,000-pound gross vehicle weight exclusion?	Make, model, trim, VIN series, model year
Completed connected vehicle	Can the vehicle perform its intended function without additional manufacturing?	U.S. import date, first sale date, ADS integration status
Covered software	Does application, middleware, or system software directly enable VCS or ADS functions at the vehicle level?	SBOM or equivalent record; proprietary additions by author name, timestamp, component name, supplier name
Software exclusions	Is the item firmware, qualifying open-source software, or a pre-March 17, 2026 software subcomponent that meets the rule’s conditions?	Maintenance history, enhancement history, change owner
VCS hardware	Is the programmable component directly connected to VCS functions that enable radio frequency communications above 450 MHz?	HBOM, FCC ID, subcomponent FCC IDs, intended make/model
Manufacturer status	Is the connected vehicle manufacturer owned by, controlled by, or subject to the jurisdiction or direction of the PRC or Russia?	Ultimate beneficial ownership, voting rights, board rights, contractual control, headquarters, principal place of business
Declaration of Conformity	Can the importer or manufacturer certify that it has not knowingly engaged in a prohibited transaction?	Due diligence record, supplier documentation, third-party assessment, document custodian
Authorization	Does a general authorization apply, or is a specific authorization needed?	Authorization conditions, 10-year records, transaction-specific support materials

Who Is Exposed

The first exposed group is the connected vehicle manufacturer that imports or sells completed connected vehicles in the United States. For a 2027 model-year vehicle with covered software, the manufacturer may need model-level records for make, model, trim, VIN series, supplier evidence, and Declaration of Conformity support.

The second group is the VCS hardware importer. Under the rule, this can include a U.S. person importing VCS hardware for integration into a completed connected vehicle intended for U.S. sale or operation, including hardware already installed in a connected vehicle or subassembly. BIS expects original equipment manufacturers and tier one and tier two suppliers to be significant affected parties, but the wording is not limited to those categories.

The third group is the supplier that may never submit directly to BIS but still has to support a customer’s filing. Telematics, wireless module, VCS software, ADS software, middleware, and build-pipeline vendors may be asked for SBOM, HBOM, third-party assessment, or ownership-control evidence.

This is where teams often lose time. Purchasing asks, “Who is the supplier?” Engineering asks, “What component is in the build?” Compliance needs the combined answer: legal entity, component, function, build record, control relationship, and documentary support.

How To Read Covered Software

Covered software is not every line of code in a vehicle. The rule focuses on software-based components in which there is a foreign interest and that are executed by the primary processing unit of an item that directly enables VCS or ADS functions at the vehicle level. BIS includes application, middleware, and system software in that concept.

The exclusions matter. Firmware is treated differently. Open-source software can also be outside covered software if the human-readable source code is fully available for use, study, reuse, modification, enhancement, and redistribution. But if open-source software is modified for proprietary purposes and not redistributed or shared, the boundary can change.

The March 17, 2026 date is another planning marker. Certain software subcomponents designed, developed, manufactured, or supplied before that date may be excluded under the rule’s conditions. If a foreign adversary-linked party later maintains, augments, or changes that subcomponent, the exclusion needs a fresh look.

A better screening question is not, “Do we have a Chinese app in the car?” It is: “Which application, middleware, and system software directly enables VCS or ADS functions, and can we identify the proprietary additions by author, timestamp, component, and supplier?”

Why VCS Hardware Needs A Separate Track

VCS refers to hardware or software installed in a completed connected vehicle that directly enables transmission, receipt, conversion, or processing of radio frequency communications above 450 MHz. The rule excludes items such as automotive sensing, ultrawideband used for key fob access, GNSS, satellite radio, AM/FM radio, and items that only supply or manage power for VCS.

VCS hardware means a software-enabled or programmable component that directly enables VCS functions and is directly connected to those functions. The rule’s examples include microcontrollers, microcomputers or modules, systems on a chip, networking or telematics units, cellular modems or modules, Wi-Fi modules, Bluetooth modules, satellite communication systems, antennas, digital signal processors, and field-programmable gate arrays. Brackets, fasteners, plastics, and passive electronics that do not support communication functions are treated differently.

The operational point is timing. Covered software becomes the near-term issue for 2027 model-year completed connected vehicles. VCS hardware requires a later but separate workstream tied to the 2030 model year or January 1, 2029 for units not associated with a model year. Service parts, warranty parts, and non-model-year hardware should not be buried inside a 2027 launch checklist.

What The Declaration Of Conformity Needs To Prove

A Declaration of Conformity is not just a signature page. It is a due diligence and recordkeeping structure that supports the claim that the importer or manufacturer has not knowingly engaged in a prohibited transaction.

For VCS hardware, the declaration record may need importer information, contact information, known FCC IDs, relevant vehicle make and model, certification that the hardware was not designed, developed, manufactured, or supplied by a PRC/Russia-linked party, due diligence certification, HBOM or equivalent records, and third-party assessment support.

For covered software, the record may need manufacturer information, contact information, make, model, trim, VIN series, certification about the software source, due diligence certification, SBOM or equivalent records, and third-party assessment support. For proprietary additions, the evidence should identify at least author name, timestamp, component name, and supplier name.

Timing is a launch issue. For completed connected vehicles with covered software, the connected vehicle manufacturer must work back from the first U.S. import or first U.S. sale for each model year. For VCS hardware, the importer works back from the first import for model-year-linked units or from the first calendar-year import for units not linked to a model year. The rule’s 60-day submission structure makes late supplier evidence a real schedule risk.

Revised declarations may be needed when a material change appears. The rule treats omissions, inaccuracies, or errors as material when they could mislead BIS about the true source of VCS hardware or covered software. A routine software update is not automatically a material change, but a change that affects the true-source analysis is a different matter.

How To Treat Authorization Paths

A general authorization is a path BIS can make available for lower-risk otherwise prohibited transactions that meet stated conditions. It is not a blanket exemption for every transaction or every company. BIS posts general authorizations through official channels, and the party relying on one must keep records for 10 years and provide them if requested.

There are limits. A party cannot use a general authorization if BIS has notified it that it is not eligible, or if the importer or manufacturer itself is owned by, controlled by, or subject to the jurisdiction or direction of the PRC or Russia.

A specific authorization is a case-by-case route for otherwise prohibited transactions that do not fit a general authorization. The application can require party information, corporate identifiers, ultimate beneficial ownership, a description of the relevant VCS hardware or covered software, affected make, model, and trim, intended function, supporting documents, mitigation evidence, and technical or operational controls.

BIS reviews specific authorizations case by case. The rule refers to a 90-day decision period, while allowing BIS to notify an applicant if more time is needed. A team planning around this route should not just ask whether an application can be filed. It should ask whether the launch schedule can wait for a decision before the transaction occurs.

The Control And Jurisdiction Point Teams Misread

The key phrase is “owned by, controlled by, or subject to the jurisdiction or direction” of the PRC or Russia. That makes the test broader than a supplier’s country label, but narrower than the nationality of an individual engineer.

The rule does not treat VCS hardware or covered software as linked to the PRC or Russia solely because one or more Chinese or Russian nationals participated in design, development, manufacturing, or supply as employees or contractors through an entity. At the same time, the entity’s principal place of business, headquarters, incorporation, organization law, voting interests, board representation, proxy voting, special shares, contractual arrangements, and formal or informal control rights can matter.

If I were building the internal review sheet, I would not stop at “country of origin.” I would separate supplier legal entity, parent entity, beneficial owner, manufacturing site, software maintainer, build or release approver, assembly or packaging party, and contractual control rights. The rule is closer to a control-and-direction analysis than a simple origin label.

2027 Model-Year Checklist

1. Identify U.S.-bound vehicle programs that fit the connected vehicle definition.
2. Separate VCS, ADS, wireless communication, telematics, over-the-air update, and connectivity-related items by model.
3. Mark application, middleware, and system software that directly enables VCS or ADS functions at the vehicle level as covered-software candidates.
4. Flag firmware, qualifying open-source software, and possible pre-March 17, 2026 subcomponents separately, then check later maintenance, enhancement, or modification history.
5. For VCS hardware candidates, collect FCC IDs, relevant subcomponent FCC IDs, intended make/model use, and HBOM or equivalent records.
6. Map design, development, manufacturing, supply, assembly, packaging, maintenance, and release approval by legal entity.
7. Add separate fields for PRC/Russia ownership, control, jurisdiction, direction, beneficial ownership, board rights, voting rights, and contractual control.
8. Assign a Declaration of Conformity owner and a document custodian.
9. Work backward from first import, first sale, or first VCS hardware import to the 60-day filing checkpoint.
10. If a general authorization may apply, document the conditions and the 10-year recordkeeping plan.
11. If an otherwise prohibited transaction remains possible, create a separate specific authorization workstream and test it against the launch schedule.
12. Create internal triggers for revised declarations or authorization review when supplier, ownership, build pipeline, or source information changes.

Watch Points

The first watch point is BIS general authorizations. Whether a transaction can fit a lower-risk authorization category depends on the posted conditions and the actual transaction structure, not on a broad reading of the rule alone.

The second is SBOM and HBOM quality. The rule does not prescribe one commercial tool, but it does require records that can support certification. If procurement files, engineering BOMs, software build records, and supplier attestations use different names and versions, the problem will surface late.

The third is model year versus calendar year. A model year is not necessarily the same as the production calendar year, and model-year-linked VCS hardware is treated differently from hardware not tied to a model year.

The fourth is supplier change. A switch made for price, logistics, or capacity reasons can become a compliance event if it changes the source analysis for covered software or VCS hardware.

Official Sources

The two source paths to keep open are BIS’s Connected Vehicles page and the Federal Register final rule. The BIS page is useful for the operational overview and agency guidance structure. The Federal Register text is the place to check definitions, timing, declarations, recordkeeping, and authorization language before making a final compliance judgment.