Finite StateFinite State
Finite StateFinite State
LoginLogin
Compliance & Regulations

How to Exclude Components Under the CVR & Why It’s So Difficult

Learn what it really takes to identify, document, and verify component origins across your supply chain to comply with the Connected Vehicle Rule.

September 12, 2025•4:18•HD•0 views

How to Exclude Components Under the CVR & Why It’s So Difficult

Transcript

the important part here is if you are in the supply chain or, ultimately, if you are a connected vehicle manufacturer or a VCS hardware importer, you are required to do a significant amount of diligence in order to be compliant here. And and let's start with this. In order to know that you don't have components that are covered, that are, you know, owned by or controlled by, you know, designed, developed, supplied by Chinese or Russian entities, you need to know what components you have as a starting point. That sounds like an easy thing to do, but with software, software is extremely complex. The supply chains are many, many layers deep, and it is very common to have software libraries that come in through those layers that you might not know exactly where that came from or what component it is. That's where, a lot of work has been going on in the security space for the last decade to try to get a much better and more automated understanding of what those bills of material look like, what your inventory of components looks like. The same thing is true on hardware where you may buy a, connectivity unit from a supplier that might be in Europe, and they might source components. They certainly source components globally that go into that, particular connectivity unit. And some of those components could come from China. And so now you are not just responsible for your relationship directly with that supplier as an OEM. You're responsible for the entirety of that supply chain leading up to you, and you have to file that declaration of conformity. So there's several things that you have to do in order to be compliant here. One is, with the software part of this, which is the earliest part that's being enforced, you need to have an entire software bill of materials, an entire software component inventory, which likely requires some amount of automation and analysis with some, some oversight by people on your team who are looking at this. You then for every software component, you need to understand whether that software component is covered or not. And, the there are some very important exclusions here that, that allow you to reduce some of this workload. For example, if the component is open source, and it's freely available on something like GitHub, to anyone in public, that is, that is excluded from the rule, because it's open source. If it is, if it meets a narrow definition of what is, described as firmware in the rule, it's also excluded. But for everything else, all of the other software, you need to understand not only the component, but who designed who designed it, who developed it, who supplied it. And that is not something that is just obvious from a simple lookup. You have to do diligence with your suppliers on that, and you have to ask them questions. That gets into the next part of this, which is you need to, in addition to software, you have to do the same thing for hardware. You have to have a hardware bill of materials. You have to have every component listed and available. You need to understand where it came from and who designed it and developed it. And then you take all of that together, and you have your list of suppliers who are involved in your supply chain. And for each one of those suppliers, you need to do diligence on the supplier to understand if they, meet those definitions that Christian was talking about earlier with respects to Chinese or Russian, controller influence. And you need to understand where the development happened and where the design happened for each one of those components. For example, you could have a US supplier that has a Chinese development team that implemented something, and you need to be able to understand, whether that was taking place. So there's actually a lot of depth that's involved here. I will I will pause there and say there's a lot of work to do. And if you haven't started this already, you might be a little bit behind. And, and and but there are there are ways to to help you, through some automation.
Finite StateFinite State

Finite State is the Product Security Automation Platform that functions as an autonomous Product Security OS: design → verify → prove, grounded in what you ship.

Platform

Platform Overview
Ground Truth Inventory
Exploitability-Based Prioritization
Design-Time Architecture Security
Automated Evidence-Backed Compliance

Solutions

Device Manufacturers
Automotive
Medical Devices
Energy & Utilities
Government
Industrial

Resources

Blog
Resource Library
Webinars & Videos
Events
Documentation

Company

About Us
CareersHIRING
Press & Media
Contact Sales
X

Privacy PolicyTerms of UseCustomer Terms and Conditions