A heavy truck scheduled to launch in 2029 may already be taking shape on an engineer's desk today. The telematics gateway, engine controller, and body-builder interface are being selected now. Those components could remain in service, running the same supplier software, well into the 2030s.
Yet heavy trucks are not covered by the federal connected-vehicle rule today. The rule applies to vehicles with a gross vehicle weight rating (GVWR) of 10,000 pounds or less. Heavy trucks sit outside that threshold, at least for now.
That could change. A bill on the Senate calendar would direct the U.S. Department of Commerce to extend the rule to heavier vehicles. The department already said, when it published the passenger-car rule in January 2025, that it plans to write separate requirements for commercial vehicles. Nothing has been published since.
For truck manufacturers making sourcing decisions this quarter, the question isn't whether they need to comply today. They don't. It's whether they'll have the information, supplier relationships, and technical processes they'll need when the rules change.
Our experience establishing the first Declaration of Conformity program with a passenger-car OEM offers a useful lesson: mapping a vehicle's software supply chain can take longer than the regulatory process itself. Manufacturers that start building that picture before they're required to will be in a much better position when the deadline arrives.
Where the 10,000-Pound Threshold Comes From
The Bureau of Industry and Security (BIS), the part of the Commerce Department that wrote the rule, restricts connectivity hardware and connectivity or automated-driving software linked to China or Russia in vehicles with a GVWR of 10,000 pounds or less. The rule is 15 CFR Part 791 Subpart D.
Heavy trucks, most buses, and large recreational vehicles fall outside that scope.
That exclusion wasn't an assurance that commercial vehicles face less risk. When BIS finalized the rule, it excluded the commercial sector because of the complexity of applying the requirements to that industry. At the same time, it made clear that the exclusion did not mean the risks were any lower. BIS also announced its intention to propose a separate rule tailored to commercial vehicles.
As of this writing, that proposed rule has not been published. The owner-operator association that opposed the exclusion argued that the delay would leave foreign-controlled technology in trucks already on the road.
The policy debate is ongoing. For manufacturers, however, the practical takeaway is straightforward: the exclusion creates time to prepare. It doesn't guarantee that today's supply chains will be acceptable under tomorrow's rules.
What a Truck Manufacturer Would Actually Have to Certify
It's easy to think of regulatory compliance as a matter of collecting supplier statements and filing the right paperwork. The passenger-car rule shows why that approach isn't enough.
Under the current rule, an authorized company officer must make a Declaration of Conformity for each model year before the first vehicle is imported or sold. The declaration carries legal weight, including potential penalties for false statements.
In practical terms, the manufacturer is saying:
- We know which software supports the vehicle's connectivity and automated-driving functions.
- We know who developed and supplied that software, and when.
- The software doesn't have a prohibited connection to a company owned or controlled by, or subject to the jurisdiction or direction of, China or Russia.
- We've performed due diligence to verify those claims rather than simply accepting what suppliers tell us.
- We maintain a software bill of materials (SBOM), or equivalent documentation, and can provide it to BIS upon request.
- Our suppliers are contractually obligated to provide the information we need from them.
- If we discover that a declaration is inaccurate, we'll report the error within 60 days and retain the required records for 10 years.
The rule itself spells out the requirements in detail. Our earlier article, Rule 791D: The Ban on Chinese and Russian Tech in Connected and Autonomous Vehicle Systems, explains the compliance pathways manufacturers have taken.
Read that list from the perspective of a truck manufacturer, and one requirement stands out: knowing what's actually in the vehicle's software.
That sounds simple until you try to do it across a supply chain involving engine manufacturers, telematics providers, body builders, and fleet-installed equipment. You can't certify what you haven't identified, and you can't verify what you can't inspect.
What the Connected Vehicle Security Act Could Change
The Connected Vehicle Security Act, S. 4429, was reported out of the Senate Commerce Committee on September 22 and placed on the Senate calendar. It has not received a floor vote and is not law.
If enacted as reported, Section 9 would direct the Department of Commerce to establish rules for vehicles over 10,000 pounds by the end of 2028, with the requirements taking effect no later than the end of 2032. The legislation would amend the same Subpart D that already applies to passenger vehicles.
Consider the implications for a truck program being sourced today. That truck could still be in production when the new rules are written, and when they take effect.
The bill would also broaden the scope of the declaration in several ways:
- More countries: North Korea and Iran would join China and Russia.
- Broader software coverage: The definition would include machine-learning models and other artificial intelligence components.
- More connectivity hardware: The scope would include electronics inside an electric-vehicle battery that monitor or communicate its state.
In other words, a future heavy-vehicle rule could bring a broader set of technologies and countries into scope than the current passenger-car requirements.
Manufacturers don't need to predict every detail of a rule that hasn't been finalized. They do need to recognize that a truck being designed today may have to meet requirements that reach well beyond the software and hardware its engineering team can readily identify.
Why a Truck's Software Supply Chain Is Harder to Map
Our perspective comes from the programs we've worked on and the industry panels we've participated in. Truck engineers will undoubtedly have their own examples, but the underlying challenge is familiar: the company responsible for certifying a vehicle may not control most of the decisions that determine what's inside it.
A passenger-car OEM generally has substantial control over its electrical architecture. It selects suppliers, manages firmware signing, and flashes modules on its own production line.
Heavy trucks are often assembled through a more distributed process.
The engine and transmission may arrive as complete systems, each with its own controllers, software, and update tools. Their manufacturers may supply the same systems to multiple truck brands. Meanwhile, the chassis-cab leaves the factory as an incomplete vehicle, ready for a multistage manufacturer or upfitter to add a body, lift gate, refrigeration unit, and the controllers needed to operate them.
The fleet operator may then install its own telematics equipment, cameras, and driver-monitoring systems, sometimes from vendors the original truck manufacturer has never worked with.
The finished truck is the product of multiple companies. Yet the officer signing its declaration may be responsible for accounting for software across all of them.
Under the passenger-car rule, the manufacturer or importer of record carries the obligation, with due diligence extending through the supply chain. Apply that model to heavy trucks, and the manufacturer could be signing for an engine controller purchased as a sealed unit and a telematics gateway it specified but never developed.
There is another complication: suppliers have their own business realities. An engine controller may serve off-highway equipment, marine applications, and generators as well as trucks. A supplier has little incentive to redesign a component for one customer's regulatory needs when the same product serves markets that aren't subject to those requirements.
These products also tend to have longer development and support cycles than passenger-car infotainment systems.
The result is a deeper supply chain, more companies involved, and fewer opportunities for the truck manufacturer to make changes quickly.
That's why the preparation matters. We saw firsthand how long it took to establish a reliable picture of software across a passenger-car fleet. A heavy-truck program faces many of the same challenges, with less direct control over the process.
What Our First Declaration Program Taught Us About Time
We established the Declaration of Conformity program for a global, multi-brand passenger-car OEM. It's the first program of its kind we're aware of, and it offers a practical preview of what heavy-truck manufacturers may face.
The starting point wasn't a complete software inventory. It was a spreadsheet full of educated guesses.
The team had a list of electronic control units (ECUs) known to have wireless interfaces, which put them in scope, along with estimates of which vehicle programs used each ECU. But the software inside those modules wasn't documented in the inventory.
This wasn't a case of someone withholding information. Nobody had previously asked the organization to assemble it.
UN Regulation No. 155 and ISO/SAE 21434 address cybersecurity risk management across a vehicle's lifecycle. The OEM had a management system designed to do that. But those frameworks don't require the same product-level accounting of software origin that this connected-vehicle rule demands.
For the first time, the team had to answer a different question: what software was actually inside the product?
At the beginning, the honest answer was that they didn't know. One of us described the situation as serving customers a dish without knowing its ingredients. It was a memorable analogy because it captured the problem so plainly.
Getting the firmware wasn't the hard part
There was one important advantage: every module's software already passed through the OEM's signing process before it could be flashed onto a vehicle.
We integrated scanning into that existing gate. Suppliers continued submitting firmware as they always had, and each submission was scanned. There was no need to introduce another form or create a separate supplier interaction just to collect the firmware.
That worked because the OEM already controlled the process.
A truck manufacturer receiving an engine controller that has been signed by the engine supplier doesn't necessarily have the same access or control. The supplier may need to provide the firmware and supporting information through a separate process.
That difference can determine how much effort is required to get the inventory started.
Analyzing the firmware took engineering work
Once the firmware was available, analyzing it presented another challenge.
File formats, packaging methods, and compiler settings varied widely. Nearly every image required an engineer from our scanning partner to unpack and analyze it manually before a bill of materials could be generated.
Coverage had to be developed one firmware format at a time.
That's an important distinction for any manufacturer evaluating a scanning solution. Collecting firmware and producing a useful inventory of its contents are two different problems. A scan may be automated at the point of submission, but the underlying analysis doesn't necessarily happen automatically.
Mapping software to vehicles was the real bottleneck
Even after identifying the software, the team still had to determine where it was used.
So far, around 13 vehicle programs have filed declarations through VSEC. Those programs rely on just five or six distinct firmware images reused across them.
The relationship between each image and each vehicle program wasn't recorded in one convenient place. The information was spread across engineering systems and teams: signing and key-management tools, diagnostics systems, requirements databases, and folders organized by vehicle architecture.
Resolving the inventory meant working through those systems manually and meeting with electrical-subsystem managers, program by program. The team confirmed the structure of every ECU for each model year, then repeated that confirmation the following year.
VSEC provides a place to record those verified relationships and make the resulting information repeatable. But the platform didn't discover the relationships on its own. Engineers and program teams did the work to establish them.
That distinction matters. A system can organize and maintain an inventory, but it can't reliably fill gaps in engineering knowledge that has never been captured.
A supplier's assurance didn't match the evidence
The clearest demonstration of why verification matters came when a supplier submitted a signed attestation stating that a module contained no Chinese code.
The supplier believed the statement was accurate. But a binary scan of the same module found code of Chinese origin in the firmware image.
The explanation was straightforward. The supplier sold the module into multiple markets and shipped a single binary worldwide. A regional configuration flag enabled entire code paths for the Chinese market, leaving those paths dormant elsewhere.
From the supplier's perspective, saying that none of the Chinese code was active was an honest answer. But it wasn't the question the declaration asked.
The rule concerns who designed, developed, manufactured, or supplied the software. Code doesn't cease to be part of the software image simply because it isn't active in a particular market.
The OEM didn't settle the issue with a clarification to the paperwork. It removed the Chinese code from the module.
Nobody involved had set out to catch the supplier in a lie. The supplier's attestation and the binary analysis simply answered different questions. Only one addressed the requirement the OEM needed to satisfy.
We later wrote about this distinction in Empty Attestation vs. Real Proof: Security Verification. It's a useful lesson for any manufacturer relying on supplier assurances to establish software origin.
The clock starts before the deadline
Taken together, these experiences explain why a late start is risky.
The OEM had to build an inventory from scratch, develop firmware-format coverage, map software to vehicle programs, repeat that mapping for each model year, and investigate a supplier attestation that didn't match the technical evidence.
And it had advantages a heavy-truck manufacturer may not have: control over its firmware-signing process and substantial ownership of its electrical architecture.
A truck manufacturer could face the same work across a longer supply chain, with more independent companies involved and fewer opportunities to collect or verify information directly.
That is the practical challenge behind the regulatory timeline. The time required to build the evidence may be much longer than the time available to produce the declaration.
What Truck Manufacturers Can Start Doing Now
None of these activities is currently required of heavy-truck manufacturers under the connected-vehicle rule. There's no need to pretend otherwise.
But the work can pay off well before a new rule takes effect. It also supports other obligations and customer expectations, including UN R155 multistage approvals in export markets and fleet customers asking what's inside their telematics equipment.
A few practical steps can make a meaningful difference.
Start with an inventory you can maintain. Identify which controllers are installed in each vehicle program, which firmware images run on those controllers, and who supplied each image. Work with electrical engineering leads to confirm the information for every model year. Treat it as a maintained engineering record, not a one-time survey.
Identify where firmware can be inspected. Determine where your organization controls firmware signing and where it relies on suppliers, engine manufacturers, or upfitters. Those boundaries matter when deciding where scanning can take place and what access agreements you'll need.
Put software-origin requirements into sourcing decisions. The next request for quotation (RFQ) for a telematics gateway, engine controller, or body-builder module is an opportunity to establish expectations. Ask suppliers to provide software-origin information and supporting evidence, and establish contractual obligations before the information becomes a regulatory requirement.
Connect the inventory to existing fleet monitoring. If you're already monitoring fleet assets, the inventory that helps you understand what's deployed is closely related to the inventory needed for a declaration. As we explored in Know the Where of Your Firmware, knowing where firmware resides is a shared need, even when different teams have different reasons for asking.
These steps won't answer every question a future rule may raise. They will, however, give your team a foundation to build on instead of forcing it to start from an incomplete inventory under a regulatory deadline.
Start Before the Rules Require It
A heavy-vehicle connected-vehicle rule isn't in force today. The legislation that could accelerate its arrival isn't law yet, either. Manufacturers still have time to prepare.
Our experience with the first passenger-car Declaration of Conformity program shows what that preparation can involve: identifying the software, analyzing it, connecting it to vehicle programs, confirming the results with engineering teams, and checking supplier claims against technical evidence.
For truck manufacturers, the challenge is compounded by the number of companies involved in building a finished vehicle and the limited control any one of them may have over the complete software supply chain.
You don't need to predict every detail of the eventual regulation to begin addressing that challenge.
If you'd like to compare notes on what may be hiding in your telematics or engine-controller firmware, and what it took us to find out during our first declaration program, get in touch with Block Harbor for a 30-minute conversation about your truck's firmware and where the gaps might be.
No slide deck. Just a practical discussion about what you know today, what you still need to find out, and how to get ahead of the work.
%201.svg){kind=logo}
