Cyber Resilience Act for Automotive Suppliers: The Car Is Exempt, but What's Inside Isn't
Most suppliers hear "automotive is exempt" and move on. The CRA carves out the finished vehicle, but a meaningful share of what they sell still falls squarely in scope.

Doc McConnell
Head of Policy and Compliance
Ask a connected-vehicle supplier whether the EU Cyber Resilience Act (CRA) applies to them, and you will often hear a quick no. The assumption is understandable: cars are already regulated for cybersecurity, so surely the CRA gives the whole industry a pass. For the finished vehicle, the assumption is mostly correct. The complication is that the CRA does not regulate the entire automotive industry. It regulates individual products, which means that suppliers need to assess CRA applicability for every item in their catalog.
Although applying the rule gets complicated, the rule itself is simple. Every vehicle sold in the EU must receive type approval before it goes on sale, which is a certification by a national authority that the vehicle meets the EU's safety and cybersecurity standards. That certification covers components designed for and included within the car by the original manufacturer, but not external or aftermarket products. Products not specifically covered by type approval are subject to the CRA, so every supplier faces the same task, product by product, of deciding which regulation applies.
How Does the Cyber Resilience Act Apply to Automotive Products?
Most product regulation is vertical, written for a single industry and its products. The CRA is horizontal, meaning that it applies across all industries, to every product with digital elements. These products include anything with software, firmware, or remote data processing placed on the EU market. The CRA is intentionally broad, intended to capture a wide variety of connected devices, including both finished products and components placed on the market on their own. This includes many devices manufactured and marketed by automotive suppliers.
Under the CRA, manufacturers have continuous cybersecurity obligations throughout a product’s entire lifecycle, which means there are commercial as well as legal implications for which regulation a product falls under. The CRA requires engineering products to be secure by default, to receive timely security updates for as long as a product is supported (at least 5 years), and to receive rapid responses to new vulnerabilities or security incidents involving those products. Meeting those requirements means building and sustaining a mature product security program over time, not just getting pre-approval before a product hits the shelves.
Why Are Finished Vehicles Exempt from the CRA?
The CRA exempts cars because the EU already regulates vehicle cybersecurity through the type-approval system and the cybersecurity management requirements that a carmaker must satisfy to sell a vehicle at all. The CRA is designed to avoid overlapping or conflicting cybersecurity requirements, so it applies only to components that are not covered as part of the vehicle’s approval process. Here is a simple test:
If a part is designed to be built into the car by the manufacturer before it goes on the lot, the CRA does not apply to it. Otherwise, the CRA does.
The logic is straightforward: the carmaker is responsible for the cybersecurity of the whole vehicle, and the parts built into it are covered through that responsibility. But if a supplier sells that exact same component independently, it isn’t covered under the vehicle’s approval, and the CRA applies.
How the CRA Works Alongside UN R155 for Vehicle Components
Consider a fleet telematics platform: the connected service that tracks a fleet's location, driving behavior, and vehicle health, along with the cloud backend and app behind it. In most cases, the telematics hardware would be integrated into the vehicle after purchase, meaning the telematics would be out of scope for the vehicle’s initial approval. The CRA applies, and the telematics manufacturer is obligated to meet CRA deadlines (including 24-hour reporting on actively exploited vulnerabilities, beginning in September 2026).
An aftermarket infotainment unit falls in scope for the same reasons. A replacement head unit, sold separately and fitted after the car leaves the factory, would not be part of the vehicle approval process. The infotainment unit would be subject to the requirements of the CRA.
Where components are covered under the vehicle approval process, suppliers may still need to demonstrate evidence of their cybersecurity. Components built into the car must not compromise the vehicle’s ability to satisfy the cybersecurity requirements in UN Regulation No. 155, such as by introducing vulnerabilities that could put the vehicle at risk. That means auto manufacturers may require suppliers to conduct risk assessments, follow certain vulnerability management practices, or provide evidence of secure data handling.
The hardest products to manage live in both worlds at once. A supplier might ship a connectivity module into factory-built cars and also sell that same module on its own, whether as an aftermarket upgrade or as a component of products in other industries. That module would be governed by the vehicle rules and the CRA simultaneously, requiring the manufacturer to demonstrate the same product’s compliance against two separate regulatory frameworks. Dual-use products like this are worth mapping early, to be sure the manufacturer understands all the obligations before the CRA takes effect.
Which Automotive Products Fall Under the Cyber Resilience Act?
The table below includes examples of components that are part of the automotive industry, but likely covered by the CRA. Each of these products is most often sold separately, developed to communicate with or be incorporated into the car after the vehicle is manufactured.
Aftermarket parts (bought on their own, outside the factory)
EXAMPLES:
• Replacement or upgraded infotainment/head unit
• Aftermarket digital instrument cluster
• Backup-camera or parking-sensor kit
• Performance "tuning" / ECU module
Standalone add-on devices (plug in or pair with the car)
EXAMPLES:
• OBD-II dongle feeding a phone app
• Connected dashcam with cloud upload
• Aftermarket GPS tracker
• Bluetooth/Wi-Fi connectivity adapter
Diagnostic & service tools (used on the vehicle)
EXAMPLES:
• Handheld fault-code scan tool
• Dealership diagnostic software
• ECU reprogramming/flashing tool
Telematics & fleet backends (connected service plus software)
EXAMPLES:
• Fleet-management tracking platform
• Cloud backend and app behind a connected-car subscription
• Usage-based insurance data box and server
V2X & charging infrastructure (systems the vehicle talks to)
EXAMPLES:
• Roadside vehicle-to-everything (V2X) units, the radios that let cars talk to traffic lights, road infrastructure, and each other
• EV charging stations and their management software
• Smart-charging controllers
Components reused beyond automotive
EXAMPLE:
• A GPS/GNSS module, cellular modem, or microcontroller, a supplier also sells into industrial, IoT, medical, or consumer markets
How Can Automotive Suppliers Prepare for the Cyber Resilience Act?
Here’s a four-step process to understand how CRA applies to you:
- List every product you sell that carries software or a network connection, and note how each one reaches the market. Is it sold to an OEM and built into the vehicle at the factory, or sold separately?
- Start with any products that fall into both categories. Gather any cybersecurity documentation that already exists. You may be able to reuse this to demonstrate compliance with the CRA.
- Then, for products that will be newly regulated under the CRA, make sure you understand the vulnerability reporting requirements that take effect in September.
- Conduct a gap analysis to understand where your products already comply, where they have gaps, and what additional documentation you need.
Suppliers may find that their products are secure, but their documentation is incomplete or outdated. That’s a good use case for the Finite State Product Security OS, which scans product firmware to show what is actually inside and aligns it to the CRA. Start now—there are fewer than 100 days until the first CRA obligations kick in.
Where to Start with CRA Compliance
Whether you already know you have products in scope, or you need help finding out, Finite State can help. Our managed CRA service pairs our platform with security experts who work alongside your people. Together, we map your portfolio product by product, line up the cybersecurity evidence you already generate against what the CRA expects, and lay out a prioritized path for the products that need work. Your team spends its time on decisions instead of detective work. The regulatory calls stay yours; we just make sure they are easy ones to make.
If you are not yet sure where your products fall, that is the most useful place to begin. Let's map it together.

Doc McConnell
Head of Policy and Compliance
Doc McConnell is a public policy and cybersecurity leader with over a decade of experience shaping national technology policy within the U.S. government. Prior to joining Finite State, he led strategic policy development for federal cybersecurity at the Cybersecurity and Infrastructure Security Agency and served as a policy advisor within the White House Office of Management and Budget.
Doc holds a Master of Information and Cybersecurity from the University of California, Berkeley, and a Master of Public Policy from the University of Virginia. He is a Certified Information Systems Security Professional (CISSP).


