Rule 791D: The Ban on Chinese & Russian Tech in Connected & Autonomous Vehicle Systems

The Department of Commerce rule banning Chinese and Russian software and hardware in connected vehicles is live and in effect. Automakers and their supply chains have until model year 2027 to comply.
If you're interested in the legal foundation or want to understand how we got here, check out the official rule page. For those who want to skip the 30+ pages of prelude and to understand what this rule means for your company, what others are doing to comply, and how Block Harbor is helping—keep reading.
First, Some Important Definitions
Rule 791D doesn't ban everything. It targets specific technologies, especially those that enable wireless communication (excluding key fobs) and automation features. Here are three important terms:
- Automated Driving System (ADS): Hardware and software that together can perform all aspects of driving, under defined conditions.
- Vehicle Connectivity System (VCS): Hardware/software that enables RF communication (over 450 MHz). Think cellular, Wi-Fi, satellite, Bluetooth.
- Covered Software: Software with a foreign interest that directly enables ADS or VCS. It doesn't include firmware or open-source code unless that open-source has been privately modified and not re-shared.
Bottom line? If you're importing or selling a connected vehicle in the U.S. with ADS or VCS features, you must ensure the enabling software and hardware weren't made or influenced by Chinese or Russian entities.
What's Required?
The rule requires a Declaration of Conformity (DoC) submitted to the U.S. Department of Commerce's Bureau of Industry and Security (BIS) before any sale or import. This isn't just paperwork. It must be signed by the CEO or a designated executive and includes detailed attestations:
- The ADS or VCS components are free of Chinese/Russian influence.
- The signatory has conducted due diligence, which can include third-party assessments.
- Supporting documentation (like HBOMs, SBOMs, vendor attestations) exists and can be furnished.
This declaration must be submitted annually and updated anytime there's a material change. For example: new software updates, supplier changes, or discovery of inaccurate prior declarations.
The Penalty?
Violations come with teeth. Civil fines up to $1M. Criminal penalties include up to 20 years imprisonment. Falsifying or concealing information can also include fines and/or imprisonment.
Are There Any Exceptions?
Yes, but they're narrow. First, there are some date related exemptions which I will explain below; there are also general and specific authorizations. The timeline on this is tight and the auto industry must move fast.
Date Related Exemptions.
VCS Hardware Importers
These are parties bringing VCS hardware into the U.S.
They are exempt from compliance requirements if:
- The hardware has no model year tie-in, and is imported before Jan 1, 2029.
- This could be general-purpose or spare parts, not associated with a specific vehicle.
- The hardware is linked to a vehicle model year before 2030, and is:
- Imported with such a vehicle, or
- Intended for repair or warranty of such a vehicle.
⏱️ Key dates:
- Jan 1, 2029: For non-vehicle-specific hardware.
- Model Year 2030: For hardware tied to a specific vehicle or model year.
Connected Vehicle Manufacturers (General)
Manufacturers building connected vehicles using covered software.
Exempt if:
- The vehicle was manufactured before model year 2027.
⏱️ Key date:
- Model Year 2027: Cutoff for general manufacturers using covered software.
Why Do VCS Hardware Exemptions Last Longer Than Software?
If this seems contradictory—it's not. All connected vehicles must contain VCS hardware, so how can hardware import be allowed until 2030, while software is banned after model year 2026? The key is that software is treated as a more urgent national security risk. Software can be updated remotely, modified post-sale, or used to exfiltrate data—making it a more dynamic threat. Hardware, on the other hand, is more deeply embedded in long vehicle design cycles. The rule allows extra time to phase out Chinese/Russian VCS hardware—but still prohibits selling vehicles with banned covered software after model year 2026.
In other words: importing hardware for pre-2030 vehicles is still allowed, but only if the software is compliant. This phased approach gives the industry more time to unwind embedded hardware dependencies while cutting off the more immediate software threat sooner.
General Authorizations.
If BIS issues a general authorization (none published as of the writing this article), you can proceed with a prohibited transaction if you meet all the terms of that authorization. Think of it as a pre-cleared exemption for low-risk cases. Keep an eye on this page for updates.
Specific Authorizations.
For all other cases, you must apply to BIS. The burden is on you to prove:
- The component presents low or mitigable risk.
- Security standards and mitigations (e.g., ISO/SAE 21434-aligned TARA, secure design validation) are in place.
- Additional safeguards, such as limited remote access or tamper-evident logging, are implemented.
This will be a high bar. This page is for Specific Authorizations.
Key Pitfalls to Avoid
- Don't rely solely on supplier self-reporting—validate everything.
- Don't stop your TARA at Tier 1—dig deeper into the supply chain.
- Don't manage cybersecurity with outdated tools like spreadsheets.
- Don't treat compliance as a one-time task—monitor threats in real time.
What the Industry is Doing
The shifting dynamic between supplier and OEM responsibility continues to move toward OEMs owning and/or being more accountable for the components in their vehicles. While some OEMs will certainly require suppliers to sign similar statements to the Declaration of Conformity, the ultimate responsibility lies with the OEM to know and understand what is in their vehicles.
Today's compliance efforts fall into a few main buckets:
- Reinforcing Supplier Due Diligence
New onboarding forms, updated cybersecurity interface agreements, and more pointed sourcing questions. - Extending Threat Assessments
If your TARA ends at Tier 1, it's time to dig deeper. Knowing where software is developed or where chips are fabbed is no longer a nice-to-know.
Scrambling for Tools
A lot of the market is leaning on spreadsheets and surveys—which only works if the people filling them out actually know where their subcomponents come from (spoiler: they usually don't).
What Block Harbor is Doing
This isn't our first time solving complex supply chain security problems. Automating portions of supply chain security is absolutely necessary due to the sheer breadth and depth of the automotive supply chain.
Block Harbor's VSEC platform already tracks cybersecurity risks across the full development lifecycle. We've extended it to:
- Parse supplier surveys, TARA, S/HBOM, etc. and automatically enrich with threat intel
- Cross-reference company names against our threat database (including where the R&D, design, or manufacturing actually happens)
- Analyze firmware uploads and extract SBOMs even when suppliers don't share them
And unlike one-time audits, our threat intelligence feeds constantly update with public disclosures, leaks, and intel from automotive cybersecurity feeds. Your supplier may not know their sub vendor has links to a restricted region or that a Chinese company just joined a joint venture with one of your suppliers—but our system will flag it.
This is part of a broader effort to make cybersecurity assessments real-time and evidence-backed, not just checkbox exercises.
What You Should Do Now
If you're already incorporating ISO/SAE 21434 compliance and cybersecurity requirements into your RFPs, you're on the right path. Now is the time to take the next step by including requirements aligned with the Department of Commerce's Rule 791 Subpart D. This allows your suppliers to anticipate new expectations and plan accordingly—well before project kickoff.
You'll also need to revisit and revise your supplier agreements and Cybersecurity Interface Agreements. These updates should reflect an increased need for transparency around intellectual property. While your ability to obtain this information will depend in part on your relationship with each supplier, you'll also need to leverage specialized tools to streamline the process.
A key capability going forward is the ability to cross-reference supplier-provided data—such as surveys, SBOMs, and HBOMs—with multiple external sources, and to validate that data against the physical components you receive.
Our Vehicle Security Engineering Cloud (VSEC) consolidates this data into one central platform, making it easy to generate reports that provide the clarity and confidence needed for Declarations of Conformity. Our research lab supports these activities further by offering scalable services to extract SBOMs, HBOMs, and related data from connected vehicle and automated driving system components.
Read More
Explore more automotive cybersecurity insights from our experts. Discover best practices, case studies, and emerging trends to strengthen your organization's security posture.

Discover strategies to protect automotive supply chains from cybersecurity threats. Learn how to identify vulnerabilities and implement effective security measures across the vehicle ecosystem.

Understand how security assurance levels guide protection efforts throughout vehicle development. Learn to determine appropriate security controls based on risk assessment.

Understand the differences between fuzz testing and penetration testing for vehicles. Learn when to use each approach and how they complement your security strategy.

Explore the current landscape of automotive cybersecurity in 2024. Learn about emerging threats, regulatory developments, and technology trends shaping vehicle security.
Try Block Harbor Today
Start protecting your vehicles with the same platform the world’s best hackers and defenders use.